System administrators guide to the Windchill Extension platform


The extension platform is available OOTB in Windchill 12.0.1 however the extension platform currently needs to be installed from the Windchill Extension Center by administrators. Installing it is fortunately easy with this installer.

This guide assists experienced Windchill administrators to understand the architecture and mechanisms used with the Windchill Extension platform.


Name Description
wex Shorthand for the Windchill Extension
wex package The windchill extension, it has a .wex extension and is a jar
wex bundle A zip or jar of wex jars that will be passed into the deployer to deploy and install .wexb
deploy Unpacking the wex jar into the windchill codebase
install Injecting the touch points and configuring windchill to use the wex
load The loading of the classes dynamically by the kernel
groupId The id that identifies the authot of the wex (e.g. com.wincomplm)
artifactId The id of the app will have the app type - name (e.g. wex-deploy)
wexid The id of the wex = groupId + artifactid (note - will become .)


WEX has a carefully designed architecture based on the concept of containerization within Windchill. Each extension is self contained and runs in a separated class loader. It does not expose APIs to the rest of Windchill and is managed by the WEX kernel. The kernel manages each extensions interaction with Windchill

file The kernel is a very small part of the system. All other features such as the Manager, Documentation, Security are developed as WEX extensions. These types of extensions are called System extensions and may not be removed from the system.

The kernel code is the only class visible to Windchill. The extensions run in a isolated classpath and are only accessible via features exposed by the kernel.


Wex Initial Install Locations

All Wex files are held in a single directory. The only initial touch point is a single startup service defined in a single .xconf

Name Description
wex All Wex files
wex/codebase/kernel.jar The wex kernel that will be loaded into the Windchill classpath
wex/packages Installed wex packages
wex/deploy Applications to be installed by the deployer

Managing Extensions

Extensions can be installed using this procedure

They may also be installed by placing the download .wex or .wexb file in the deploy area. The next time any server restarts, it will deploy the extensions in this location.

Extensions, except system ones, may be uninstalled.

Updating Extensions and System

When new extensions are downloaded, they are downloaded with the wexb extension. This is a format containing 1 or more extensions. The WEX center will include newer system extensions, as and when needed, to ensure that the client’s system is up-to-date.

Server Startup Procedure

The servers will deploy any WEX that are in the deploy area. In the case of a multi methodserver machine, the first server to be initialized will perform all the deployments. Once it is complete, the other servers will register the new extensions.

The following environment variable must be set to enable this feature



The wex uses a lock file to signal to the other servers that it is the master during initialization. This file is here


If the master crashes or is aborted during startup, this may cause a temporary pause in the wex initialization sequence. The slave servers will verify (using an id stored in the lock file) that the master is still alive. However, if after 3 attempts there is no response from the master, one of the slave servers will gain the lock and become the new master.

Note that this is a typical trace in this case


Security and Signing

Every wex extension is signed for use by a specific client. If any file is altered then the digital signature will become invalid and the wex will no longer be loaded by the kernel.

It must be removed and re-deployed to correct this error.


The WEX diagnostics extensions provides tools to assist in troubleshooting issues


This extension willl show the status of the current server and print in the logs of all servers the status of the kernel


The WEX shell

By executing the following command

windchill com.wincomplm.wex.kernel.commands.WexCommandLineExecutor -u wcadmin -p wcadmin -pid com.wincomplm.wex-system -cid shell

a Wex shell will be made available that can be used to interrogate the running kernel on a server


Was this article helpful? Votes: 4
Article details:
Published date: 02/08/2019 11:03AM
Last updated: 22/03/2021 12:03PM ( -
Share article: 
Author: dkanalec (