Using Binary Shared Modules in your Project
To use a binary shared module, you begin by importing the archive into your workspace where it appears like any other shared module, except that the internal details of the shared module are not visible. You use a binary shared module in the same way as you would use any other shared module.
- Process and package name
- XML schema files associated with the module
- Shared resources - you can reference them, but cannot edit them
- Module Descriptor folder - only the Overview item is available under this folder
- Module Descriptor editor will be able to display the Overview page only. All other fields will be disabled
You can implement a Call Process activity that invokes the functionality in the binary shared module. When deploying your application, the binary shared modules are included in the application like any other shared module.
Difference between a Shared Module and a Binary Shared Module
This section describes the difference between a shared module and a binary shared module.
In Project Explorer
The image below shows you the difference between a shared module (shared5, in the image below) and a binary shared module (shared4). Notice that almost all the editable artifacts (such as Module Properties, Dependencies and Shared Variables) are missing from the binary shared module tree. This is one way to prevent the binary shared module from being edited.
At the project level some of the context menus items are disabled in the binary shared modules. At the resource level all the menu items except for Show Properties View are disabled.
Public Processes and Internal Processes
A binary shared module can contain two types of processes - public processes and private (internal or inline) processes. While a public process in a binary shared module can be called by an application, a private process within the module is meant for consumption by the public processes within that binary shared module only. By default, the private processes are not visible in the Project Explorer.