System administrators guide to the Windchill Extension platform
Introduction
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.
Terminology
| 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 .) |
Architecture
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
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
WEX_INSTALL_AREA_ON_STARTUP_ENABLED=true
The wex uses a lock file to signal to the other servers that it is the master during initialization. This file is here
wex/wex.lock
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.
Diagnostics
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
