Work with the Process Center repository

Process Center repository

You can use the Process Center repository to share artifacts with other users who are developing process applications and toolkits.

IBM Integration Designer supports a range of servers, runtime deployment environments and capabilities. Make sure that you have enabled the capabilities and features for which you are licensed in order to perform tasks such as those in this section. See Business integration capabilities for information on capabilities and functions.

To work with the Process Center repository, you must know how to access it, import process applications and toolkits from it, and associate modules and libraries with its process applications and toolkits. You must also know how to use the wizard that generates a service that a process application might require. Finally, you must know how to synchronize your artifacts with their associated process applications and toolkits, deploy a completed process application or toolkit, and understand the limitations when you are working with the Process Center repository.

Access the Process Center repository

To work with process applications and toolkits, access the Process Center repository.

To access the Process Center repository:

1. In the upper-right corner of the development environment, click Process Center.

2. Complete one of the following steps:

   • If you have connected to a Process Center repository previously or if you installed Integration Designer from the Process Center, then the Process Center view will open.

   • If you have not connected to a Process Center repository previously, enter the following information on the subsequent page.

3. In the repository window, enter a URI to connect to the IBM Process Center repository, in the following format: http://<server name>:<port number>/ProcessCenter; for example, http://myserver.toronto.com:9080/ProcessCenter. Enter the user ID and password. Click Connect.

4. The Process Center repository view opens.

   When you enter a URI, it is recorded in the Preferences page. To see the current URI, select Window > Preferences > Business Integration > Process Center.

If your connection to the Process Center fails, you should check the port is accessible. One reason the port may not be accessible is that it is behind a firewall.

If Integration Designer cannot add the Process Center as a server, you should check the BOOTSTRAP_ADDRESS port (default is 2809) of the Process Center is accessible. One reason the port may not be accessible is the Process Center is behind a firewall and Integration Designer is outside the firewall.

Import process applications and toolkits from the Process Center repository

You can import process applications and toolkits into your workspace from the Process Center repository, and then you can use them with your modules and libraries.

You must have permission to write to the temporary directory the operating system uses during the import process.

To import artifacts from the Process Center repository into your workspace:

1. From the Process Center repository, select a process application or toolkit.

2. Click Open in workspace. The process application or toolkit is imported into your workspace, and you can view it in the Business Integration perspective.

   If you experience difficulty when importing a process application or toolkit, check that you have Write and Administrator authority on them. If you have difficulty updating a process application or toolkit, check that you have Configurator, Operator and Deployer administrative security roles. If you are not currently assigned to all of these roles, click Users and Groups in the WebSphere administrative console and modify the user or group roles.

Related concepts:

Manage the Process Center repository

Manage access to the Process Center repository

Manage access to process applications and toolkits

Switching between simple and advanced mode

You can customize your mode of operation to show only what you need.

There are two modes of operation: simple mode and advanced mode. The advanced mode shows all the files that are associated to your process application or toolkit. The simple mode shows you only the advanced integration services, processes, data, and interfaces. The simple mode hides artifacts of the SCA programming model such as modules, libraries, and the assembly diagram. This lets you implement an advanced integration service simply, by right-clicking on the service and selecting the component type for your implementation.

With simple mode, an advanced integration service can only be implemented by one component. With advanced mode, Integration Designer projects are shown explicitly and the artifacts are located under their respective containers. Use advanced mode to work with the assembly diagram to create more complex services and share artifacts with Process Designer.

You switch between simple and advanced mode by clicking the mode icon in the Business Integration view. The mode icon toggles between the simple mode and the advance mode

To switch between simple and advanced mode:

1. To switch to the simple mode from the advanced mode, click the mode icon ().
2. To switch to the advanced mode from the simple mode, click the mode icon.

Associating a module or library with a process application or toolkit

You can associate a module or library with a process application or toolkit to add additional functions to the application, or to take advantage of version control on the Process Center.

If a module that contains a long-running process has been deployed to a process server and you now want to associate the module with a process application, you should first consider whether you want to migrate your process instance:

• To migrate the process instance, create a new process version before you associate the module with the process application. You can create a new process version by right-clicking your module in the Business Integration view and selecting New Process Version.

• If you do not want to migrate the process instance, you can proceed to associate the module with the process application by following the instructions in this topic.
• See the guidance and limitations topics listed in the Related reference links for information on working with the Process Center.

There are wider implications to associating a module or library with a process application or toolkit than you might first see. Modules and libraries associated with toolkits can be shared with other process applications in addition to the one in your workspace. Modules and libraries that are associated with process applications are also visible within the process application. Remember too that when you bring a process application or toolkit into your workspace, you may be bringing in a snapshot, which is a previous point in time.

If you are developing iteratively and have changed the name of a module or library (or the scope of a library) since you first associated it with a process application or toolkit, see the "Scope and naming considerations for associated modules and libraries" link at the end of this topic.

To associate a module or library with a process application or toolkit:

1. In the Business Integration view, right-click the module or library that to add to your process application or toolkit. From the menu, click Associate with Process Center. The Associate with a Process Application or Toolkit window opens.

   The Associate with a Process Application or Toolkit window also appears when use the wizard to create new artifacts in IBM Integration Designer such as modules, libraries, and monitor models.

2. From the Select the process application or toolkit that will contain the projects list, select a process application or toolkit.

3. In the Select the projects to associate pane, you can see the projects in your workspace that are available for association. Select the modules or libraries to associate with your selection. Click Select All to select all the modules or libraries that have not been associated with a process application or toolkit. Click Select Referenced to select modules or libraries referenced to the selected item. For example, click Select Referenced to add a library to the selected list if a selected module had a dependency on that library.

   You stop sharing certain file types by setting IBM Integration Designer preferences in Windows > Preferences > Business Integration.

4. Click Finish. The process application or toolkit is brought into the workspace and you can see the associated modules and libraries below it in the Business Integration view.

   IBM Integration Designer aggregates all artifacts into one integrated process. See the Guidance topic for more details. For information about limitations that may exist when associating projects with process applications, see "Limitations when working with process applications and toolkits."

Transitioning from modules and libraries to process applications and toolkits might require updates to some of your artifacts that are contained in your modules and libraries. For example, if your module contains BPEL processes, human tasks or state machines, the validFrom dates for those artifacts are removed (as versioning for BPEL processes used in process applications or toolkits is done in the Process Center using snapshots). If a BPEL process migration specification refers to a validFrom date, that process migration specification is also updated.

Disassociating a module or library from a process application or toolkit

When you disassociate a module or library from a process application or toolkit, you remove the association between the workspace and Process Center artifacts. You disassociate a module or library when it is no longer needed by the process application.

You can disassociate a module while you are connected to the Process Center. After you disassociate, you can (if you so choose) move that disassociated module to another process application or toolkit. If you are disconnected from the Process Center, you can disassociate a module only if you plan to copy that module to another process application, toolkit or process center. You need to switch to the advanced view so you can see the module that you are disassociating. See the "Switching between simple and advanced mode" topic in the related link section.

Restriction: When you disassociate a default project ( the default module: PA_Implementation or the default library: PA_Library), you cannot then reassociate the same default project that you have disassociated. To associate the disassociated default project back to the Process Center, you must rename the project before you can associate it to the same process application or toolkit in the Process Center. If a process application does not have a default project associated to it ( the default module: PA_Implementation or the default library: PA_Library), when you open that process application in your workspace, a default project is automatically created.

To disassociate a module or library from a process application or toolkit:

1. To disassociate a module or library:

   1. If you are connected to the Process Center, right-click the module or library you want to disassociate from a process application or toolkit. From the menu, click Disassociate from Process Center. A message warns the module or library will be disassociated from the Process Center, where other people might have been using it.

   2. If you are disconnected from the Process Center, right-click the module or library you want to disassociate from a process application or toolkit. From the menu, click Disassociate. A message warns the module or library will be disassociated from the process application or toolkit only in your workspace. Your modules and libraries will still be in the Process Center.

2. Check if there are other modules and libraries with a dependency on the module or library that is being disassociated. Disassociate those modules and libraries also and remove their dependency. If the module or library is refactored and is still needed by these other modules and libraries, associate them again with the refactored module or library and add the dependencies back.

3. Click Yes to continue or No to leave the module or library in its present state.

When a module or library is disassociated:

• Connected to the Process Center - When you disassociate a module or library while you are connected to the Process Center, it is removed in the Process Center and your workspace from the process application or toolkit it was associated to. The module or library that was disassociated remains in your workspace, outside of the process application or toolkit, in the Business Integration view.
• Disconnected form the Process Center - When you disassociate a module or library while you are disconnected from the Process Center, it is removed only in your workspace from the process application or toolkit it was associated to. The module or library that was disassociated remains in your workspace, outside of the process application or toolkit, in the Business Integration view. You cannot reassociate the same module to the process application or toolkit it was disassociated from.

Transitioning from process applications and toolkits to modules and libraries might also require updates to some of your artifacts that are contained in your modules and libraries. For example, if your process application or toolkit contains a BPEL process migration specification (that might use the snapshot versioning process), all BPEL process migration specifications will be deleted.

Related tasks:

Switching between simple and advanced mode

Getting updates from the Process Center repository

Process applications and toolkits are often updated by users. The Refresh from Process Center command updates your workspace with relevant changes that have taken place on the Process Center; for example, changes to toolkit dependencies. To use the Refresh from Process Center command:

1. Right-click the process application or toolkit to update.

2. From the menu, click Refresh from Process Center.
3. All changes on the Process Center that do not conflict with your workspace are merged with your workspace. See Synchronizing the workspace artifacts to the Process Center repository.

Sending updates to the Process Center repository

As you update your process applications and toolkits, you will want to likewise update the corresponding process applications and toolkits in the Process Center with your changes. The Publish and Refresh command updates the Process Center with the changes in your workspace.

Note that publishing is not available from IBM Integration Designer on a Process Center that has not been upgraded. To use the Publish and Refresh command, follow these steps:

1. Right-click the process application or toolkit in your workspace to update in the Process Center.

2. From the menu, click Refresh and Publish.
3. The process application or toolkit is updated. Should there be a conflict because an element in your workspace and an element in the Process Center are identical then you are warned to proceed. If you proceed, the element in the Process Center is overridden. See Synchronizing the workspace artifacts to the Process Center repository.

As time moves forward you will make updates to the WSDL files you created. For synchronization purposes, the Refresh and Publish command assumes you will make your updates with the Interface editor or the Business Object editor where you created your WSDL file. Always use these editors for updates. If you use another editor such as a text editor, the result will be no synchronization with the Process Center.

Related tasks:

Publishing modules to test environment servers

Performing a rolling upgrade

Create servers for process applications

Development and deployment version levels

Deploy service modules

Implementing an Advanced Integration service

If a process application in your workspace requires an Advanced Integration service, you can use a wizard to create the basic components that you need.

This procedure describes the Detailed Mode. In Simple Mode, there is an Implement link under the AIS in the Business Integration perspective. Clicking this link launches the wizard.

To start the wizard and generate a basic implementation for a process application:

1. From the Business Integration view, expand the process application and the Advanced Integration Services folder. Right-click the service to be implemented (it is marked unimplemented) and then click Implement.

2. Select the implementation type from the following list and click Finish.
   • Microflow. Select this option if your service will start a business process that provides an immediate response. An export and a business process set to a microflow are created.
   • Long-running business process. Select this option if your service will start a business process that runs for an extended time; that is, if it does not provide an immediate response. An export and a business process set to a long-running process are created.
   • Java component. Select this option if your service will be implemented in Java. An export and a Java component are created.
   • Empty implementation. Select this option if you have not decided on the implementation use. An export is created but it is not wired to a component in the assembly editor. Later you can create a mediation flow, state machine, an interaction with another system through an adapter or some other implementation.

   Preferred interaction style determines if a synchronous or asynchronous mode of communication is used. If your Advanced Integration service is interacting with modules through imports and exports, check their preferred interaction style as it may affect your performance expectations. For example, you may select an implementation type of microflow expecting a synchronous communication mode with an immediate response. But the implementation may include modules with JMS bindings that send data asynchronously which could result in data waiting in queues.

3. You can now see the components in the assembly editor, and the Advanced Integration service is marked implemented. You must still develop the implementations because only a shell has been created.
4. Once you have developed your implementation, use the Refresh and Publish command to update the corresponding information in Process Designer.

If you are associating more than one module, a window shows that prompts you to select a location to save your modules to.

When the Advanced Integration service wizard finishes, the appropriate editor opens in the implementation (an editor such as BPEL or Java). In the case where no implementation is selected, the assembly editor opens only if you are in Advanced Mode. If you are in Simple Mode, the option, Empty implementation, does not show.

Related tasks:

Building an Advanced Integration service

Create an export to implement an Advanced Integration Service

Creating an export is an alternative way to implement an Advanced Integration Service. If you drag-and-drop icons from the assembly editor palette to create exports, this approach could be a simpler way for you to implement the service.

To create an export to implement an Advanced Integration Service, follow these steps:

1. First associate a module with the process application containing the unimplemented Advanced Integration Service if you have not done so.

2. From the assembly editor palette, expand Inbound Exports, select Advanced Integration Service and drag it onto the canvas. Select the Advanced Integration Service that can be implemented from the window.

3. Click OK. An SCA export, one with an SCA binding, is created in the assembly editor that is associated with the Advanced Integration Service in Process Designer. It has no implementation.
4. An alternate way to create the export is to drag the unimplemented Advanced Integration Service from the Business Integration view on to the assembly editor canvas. An export with no implementation is created.

10. Create an import to start a business process definition

A service might need to start a business BPD instance to enable a human-centric interaction with the service. For example, the service might encounter an unexpected business situation and need human interaction to resolve it. An SCA import can be created to start a BPD instance.

For imports that start a BPD from a Service Component Architecture (SCA) module, the authenticated user role must have at least deployer and monitor roles.

To create an import to start a BPD, follow these steps:

1. From the Business Integration view, expand the process application and right-click the BPD you want to start. The available BPDs are listed under Processes. Select Create Import. Alternately, on the assembly editor palette you can expand Outbound Imports, and then select Business Process Definition, drag it onto the canvas and select the BPD from the dialog box. You can also do one of the following procedures:
   • Drag the BPD from the Business Integration perspective onto the assembly editor canvas: Drag the BPD on the assembly editor canvas.
   • Drag the BPD from the Business Integration perspective directly into the BPEL editor: When you drag the BPD into the BPEL editor, it automatically creates an import and reference.

2. Select the invocation style to use:

   • Use a request-response invocation (default): This invocation style starts the BPD and waits for the BPD to respond back with any output.

   • Use a one-way invocation: This invocationstyle starts the BPD and expects no response to be returned from the BPD.

3. An import is created and added to the assembly editor canvas.

11. Making operations visible to process applications

If you have an SCA export and implementation, you can make it visible to Process Designer as an Advanced Integration Service. For example, you may have an operation that provides business intelligence data on a subject linked to a process application. By making the operation visible, the process application can now use that data.

To make operations visible to a process application:

1. Associate the module that contains the operations with the process application.

2. Open the assembly editor and select an SCA export (that is, an export with an SCA binding) that contains the operations to make visible to the process application.

3. In the Properties view, select the Binding tab. Select the Make operations visible to Process Designer check box. All operations become visible.

   Save your work. Once you use Refresh and Publish on the process application or toolkit, a corresponding Advanced Integration Service will be created in Process Designer which can be used in the Process Designer business process.

   Note that deselecting the check box removes the implementation.

   You should read the Limitations when working with process applications and toolkits section as there are some restrictions on implementations used with Process Designer.

12. Examining the Process Designer configuration

You can launch the Advanced Integration service configuration in Process Designer corresponding to your Advanced Service implementation, which can be helpful when you are developing the service in Integration Designer. To launch the configuration Process Designer must already be open.

1. Right-click the Advanced Service implementation in your workspace to open in Process Designer.

2. From the menu, select Open in Process Designer.
3. In Process Designer, the Advanced Integration service configuration corresponding to your implementation opens.

13. Emulating an advanced integration service

You can choose to run an implemented advanced integration service in the emulate mode, which means that you do not actually need to run the service during playback. You can emulate the interactions of the service by manually entering the outputs. This is useful to test the business process when the service is not available.

Emulation is automatically turned on for advanced integration services that are not yet implemented. To emulate an advanced integration service that has been implemented, explicitly turn on emulation. To emulate an implemented advanced integration service, follow these steps:

1. Open the advanced integration service in Process Designer and select the Emulate Service check box.
2. When you playback the business process, an emulation coach will be displayed when the service is encountered.

3. Enter the outputs of the service in the coach and click OK.

If the advanced integration service is deployed to an external repository then the user at the external repository must have at least a monitor administrative security role to use the advanced integration service.

When emulation is turned on for an advanced integration service, the service will always be emulated during playback in the Process Center. If the service is deployed to the Process Center, you will see the emulation coach if the service and implementation are not synchronized.

The emulation coach is also launched if deployment of your process application to the Process Center is in progress. In that case, you will see a Postpone button in the emulate coach. You can then select postpone if you do not want to emulate the service, but want to wait until the actual service has been executed so that you can rerun the advanced integration service. Postpone is only available if the service would have been executed if it was deployed to the Process Center.

If you use complex output parameters, the generated form may exceed the maximum length of characters allowed. The generated HTML code needed to emulate the Advanced Integration Service may not be created. If you experience this problem, simplify your existing Advanced Integration Service or disable the emulation. Alternatively, if you have not implemented your service, implement it as emulation will automatically be invoked each time the service is used with no implementation.

If you are emulating a bottom-up service that is backed by a Web Services Description Language (WSDL) binding with inline types, it causes the advanced integration service to be out-of-sync, and you must synchronize the IBM Integration Designer implementation again. Avoid emulating bottom-up services for WSDL bindings with inline types.

14. Change toolkit dependencies

A process application can reference only one toolkit snapshot but that reference can be changed. To change the toolkit snapshot that is referenced by a process application:

1. Right-click Dependent Toolkits in the Business Integration view. Select Change Toolkit Dependencies.

2. Select the snapshot of the toolkit you want to reference from the window. Only one snapshot will be selectable from any toolkit.

3. After your selection, the dependent toolkit snapshots are listed under Dependent Toolkits.

   If you select two or more dependencies that contain the same project name, a message tells you that a project name cannot be used more than once in a process application or its dependencies. Clear the selection or selections that you do not need.

When you change the toolkit snapshot, this action affects the service you have created since the process application and modules may have referenced elements not in the new toolkit snapshot. In such cases you need to add these elements to the new toolkit snapshot, or modify your service.

15. Loading snapshots to the workspace

To view and manage a specific iteration of a process application and toolkit, you can download a snapshot to your workspace. A snapshot is a capture of a process application or toolkit, at a specific point in time.

You can load a snapshot to your workspace directly from the Business Integration perspective.

To load a snapshot to your workspace:

1. Switch to the Business Integration perspective.
2. Right-click the process application or toolkit and then click Replace With > Another Snapshot.

3. Select the snapshot to load to your workspace in the Select a Snapshot window, and then click OK.

The snapshot of the process application or toolkit that you selected is brought into the workspace. Any referenced toolkits are also brought to the workspace. The associated toolkit has a decorator next to the file name to indicate that a snapshot has been brought into the workspace. The snapshot is also identified to the right of the file name.

16. Synchronizing the workspace artifacts to the Process Center repository

While you are updating an artifact, another user might be updating the same artifact at the same time. To make sure that you are using the latest version of an artifact, you must synchronize the versions that exist in the workspace and the Process Center repository.

As you and others work on an application, the modules, libraries, process applications, and toolkits might change. Conflicts occur when two users have made changes to the same artifact, within the same parameter at the same location for example: changing interface InfB in human task HumanTask1.

When you try to publish the artifact to the Process Center, synchronization automatically starts to merge changes into the workspace. If there is a conflict, the conflict shows in the Synchronization window. You must resolve the conflict before you can publish your changes to the Process Center.

To make sure that you are using the latest version of an artifact, you must synchronize the versions that exist in the workspace and the Process Center repository. Select the file that contains the changes you want to keep, and then click Commit to publish your changes to the repository.

When you are synchronizing your workspace to the Process Center, you can do it directly from Changes in Selected Artifacts pane, or from the Change Details pane. Some file types are easily synchronized from the Changes in Selected Artifacts pane. Other file types must be synchronized manually from the Change Details pane. The following synchronization guidelines apply:

• For an XSD, WSDL, or assembly diagram, you need to go to the Changes in Selected Artifacts pane and accept the changes you want to keep or import. You do not have to select and commit the file.

• For other artifact types, you have to manually copy the changes from the repository to the workspace in the Change Details pane.

When you have nonconflicting changes:

• Select the changes you want to bring into your workspace by clicking the check box next to the change.
• Clear the changes you do not want to bring into your workspace.

• Click Commit.

When you publish changes to the repository that include updates to the tip of a referenced toolkit, you must generate a new snapshot of the tip. The new snapshot must have a unique name.

To synchronize conflicting artifacts:

1. You can set preferences to always view the Synchronization window, or to view it only when a conflict occurs. To specify how you want the Synchronization window to function, select one of the following options:

   • You can set the Synchronization window to show each time you publish by selecting Always in the Preferences page. To set this preference, click Windows > Preferences > Business Integration > Process Center.

   • You can set the Synchronization window to show only when there is a conflict by selecting Open when a conflict is detected in the Preferences page. When you publish your artifacts to the repository, all changes are merge silently into the workspace. To set this preference, click Windows > Preferences > Business Integration > Process Center.

   Go to step 2 to synchronize assembly diagram, WSDL, and XSD artifacts. Go to step 3 to synchronize all other artifact types.

2. To synchronize assembly diagram, WSDL, and XSD artifacts:
   • The Synchronization window shows you the changes in your workspace and the repository.

   • Select which change you are going to keep by checking the box next to those changes in the Changes in the Selected Artifact Pane, and then click Commit.

   You can synchronize only those files that are marked with a mirroring flag. Module and library names must be unique within a deployed process application.

3. To synchronize all other artifact types:
   • The Synchronization window shows you the workspace and repository changes in a text-based compare/merge window in the Change Details pane.
   • Copy the changes from the repository file to your workspace file, and then click Commit.

17. Change connection properties for process applications and toolkits

If your process applications and toolkits are moved to another server, for example, because of a hardware failure, update your connection properties.

To update the connection properties of a process application or toolkit, follow these steps.

1. Right-click the process application or toolkit whose connection properties must be updated. From the menu, select Window > Preferences.

2. In the Preferences window, expand Business Integration > Process Center. Update the Process Center URI field with the new connection information.

3. Click OK to save the updated connection properties.

18. Renaming a module or library associated with a process application or toolkit

If you have modules and libraries associated with a process application or toolkit, be aware that renaming the module or library requires you to remove any dependencies and to disassociate the library or module before changing its name. A module or library that has been associated with a process application has a relationship with both the Process Center and the workspace. If, during iterative development, you change (refactor) its name and then publish the updated module or library, you might experience deployment failures or unexpected behavior in the process application or toolkit.

To avoid problems, follow these steps when renaming a module or library that is already associated with a process application or toolkit.

1. Ensure you are logged in to IBM Integration Designer with the necessary permission.
2. (Library only) Remove any dependencies on the library.
3. Disassociate the library or module from the process application or toolkit.
4. Rename the library or module, using the refactoring function.
5. Associate the renamed library or module with the process application or toolkit.
6. (Library only) Reinstate any dependencies you removed.

Related tasks:

Modules and libraries dependencies

Associating a module or library with a process application or toolkit

Disassociating a module or library from a process application or toolkit

Sending updates to the Process Center repository

19. Import an SSL security certificate into Integration Designer

In order to connect to an HTTPS enabled server, you need to import the SSL security certificate (X509Certificate ) for the server.

The steps described in this procedure are performed using Internet Explorer. To install copy of the SSL security certificate into Integration Designer.

1. Launch your web browser and enter https://hostname:secure_port/ProcessCenter/login.jsp where hostname is the fully-qualified domain name of the process center server and secure_port is the process center secure SSL port number.

2. On the Security Alert window, click View Certificate.

3. On the Certificate window, click the Details tab.
4. Click Copy to File to specify where to save the certificate file on your system.

5. In the wizard, click Next, accept the default values, and then click Next again.

6. Enter a file name for the security certificate, for example, pc_cert.cer, and click Next.
7. Click Finish.

   After creating the SSL certificate, you can import it into the Java JRE that you will be using for Integration Designer.

8. Copy the certificate to IIDInstall\jdk\jre\bin where IIDInstall is the directory where you installed Integration Designer.
9. Switch to the same location on the command line and run the keytool command:
   1. keytool.exe -import -v -file <certificate file> -keystore ..\lib\security\cacerts If you previously imported SSL certificates into the Integration Designer, add the -alias <key name> parameter to specify a different key name to avoid name conflicts. The default value is mykey.

   2. Enter the keystore password: changeit (this is usually the default password)

   3. Enter y at the prompt to trust the certificate.

20. Library mirroring

In a collaborative development environment between IBM Integration Designer and Process Designer artifacts like business objects are shared in libraries. Library mirroring means that when you put an artifact in your library in Integration Designer it is made available to others working with the same library in Process Designer who are using the same process application or toolkit.

When you bring a process application or toolkit into your workspace, the libraries associated with them have library mirroring enabled. You cannot change the setting.

When you associate a library in your workspace with a process application or toolkit that you have brought into your workspace, library mirroring is not enabled by default. You can enable library mirroring to share the artifacts in your library in Integration Designer with Process Designer.

To see if a library has mirroring enabled and, if permitted, change the setting, right-click the library and from the menu select Properties > Business Integration > Library Mirroring. A check box beside Mirror the library as soon as it is associated with the Process Center determines if mirroring is enabled.

There may be circumstances when you may not want users in Process Designer changing artifacts. For example, you may have business objects for a standard financial report used in your corporation that must be left as is. Consider setting up users and groups and restricting access to only those who are authorized to make updates to the artifacts.

21. Guidance when working with the Process Center

Associating modules and libraries with process applications and toolkits in the Process Center changes the way that you work based on previous releases.

This topic provides some tips and guidance for working with the Process Center.

• Bindings interact with process applications and toolkits differently than with components in modules. See Considerations when using bindings.
• When deployment occurs from the Process Center, a shared library is shared with all the modules in the process application. If you deploy a module independent of the Process Center, the libraries are not shared. Each associated library is copied into each module.
• Snapshots in the Process Center repository are the equivalent of versioned files in previous releases. Therefore, modules and libraries that are associated with process applications and toolkits cannot be versioned.
• Snapshots are set to read-only when brought into IBM Integration Designer.
• Certain file types should not be stored in the Process Center repository. In some instances, certain file types may interrupt your build. In other instances there is no need to share them. By disabling sharing you can contain the size of your project. The following file types should not be stored or shared on the Process Center repository:
  • Metadata such as "team private" files. Files of this type can cause build issues as team private files contain tracking information specific to the workspace they were generated in.
  • Any derived files.
  • File types such as wbiexetrace, smap, or jsrc files.

  You can set preferences to ignore specific file types in Windows > Preferences > Team > Ignored Resources.

• Although the Process Center cannot incorporate changes from Business Modeler, you can export your projects from Business Modeler and import them into Process Designer, which will allow you to interact with these business processes.
• A process application or toolkit must contain a default module or default library in order for you to open it in IBM Integration Designer. When you first open a process application or toolkit in Integration Designer, it is automatically initialized by associating a default module or library.

  In the Process Center, when you open a process application that depends on a toolkit, and that snapshot of the toolkit does not contain a default module or library, you can do one of the following:

  • Continue to open the process application with the toolkit. However, the tip of the toolkit is brought into your workspace and not the snapshot. You cannot bring the snapshot into your workspace because a snapshot is read-only and cannot be initialized. If the tip was not initialized, once the tip is brought into your workspace, it is automatically initialized. You can then create a new snapshot from the tip and update the dependency from the process application.
  • Clear the toolkit in the Open in Workspace window. You can proceed to open the process application if you are certain that you will not be using any artifacts from the toolkit that you cleared.

22. Considerations when using bindings

Different bindings interact with process applications and toolkits in various ways. You should consider the following suggestions and be aware of some rules and conventions.

• Bindings with process applications and toolkits overview
• Rules to calling process applications and toolkits with different bindings
• Versioning and bindings
• Resource creation by binding

Bindings with process applications and toolkits overview

The available bindings to use when invoking services are:

• SCA
• Web Service
  • SOAP/HTTP 1.2 JAX-WS
  • SOAP/HTTP 1.1 JAX-WS
  • SOAP/HTTP 1.1 JAX-RPC
  • SOAP/JMS 1.1 JAX-RPC

• EIS (Java EE connector architecture)
• Messaging
  • JMS
  • Generic JMS
  • MQ
  • MQ JMS

• HTTP
• EJB

The simplest of these to use within Process Server, because it is a version aware binding and manages its own resource, is the SCA binding. For example, you do not need to be concerned about issues that know for other bindings, such as using the correct context root for a URI in a HTTP binding, managing a destination queue in a message binding, or setting up security for a web service policy binding. IBM recommends that use the SCA binding as your default binding of choice, except when you need to use one of the other bindings.

Some examples of when you would use a non-SCA binding are as follows:

• You want to call an existing service which is exposed using one of these other bindings. For example, you may want to invoke a SAP BAPI, a web service, or a MQ service.
• You are exposing your service or process to external clients who do not have access to the SCA binding.
• The service you are calling may take a long time, so you need to use a queue.

Rules to calling process applications and toolkits with different bindings

The following diagram shows examples of binding calls with process applications and toolkits. Any cross-module calls within a process application (PA1 - PA1, PA1 - TK1, or TK1 - TK1) should be done using the Service Component Architecture (SCA) binding.

The process applications, toolkits, modules, imports and exports are indicated as follows:

• Process applications: PA1, PA2
• Toolkits: TK1, TK2
• Modules: M1, M2, M3, M4, M5, M6
• Export: E (not enumerated)
• Import: I (not enumerated)

You should not make the following calls:

• From a toolkit to a service in its containing process application (TK1 - PA1)

• From a process application to a service in a toolkit of another process application (PA1 - TK2)

• From a toolkit in one process application to a service in a toolkit of another process application (TK1 - TK2)

• From an external application to a service in a toolkit (EIS - TK1).

When making cross-process application calls you can use the SCA, Messaging, HTTP or web service bindings.

When calling an external application or an external application is invoking your service, any of the bindings may be used.

Versioning and bindings

Your process or service may be designed so that it requires that only one instance of it is ever deployed, or that co-deployment of different versions are deployed. You will need to consider the lifecycle of the process or service, such as maintenance (that is, fixes) and enhancements to the process or service as you receive new business requirements. Enhancements may have non-breaking changes (such as adding a new operation) or breaking changes (such as modifying a business object). Depending on your service agreements, you may need to support co-deployment.

Your process or service is versioned when you use a process application and Process Center. This will affect the provider of a service, in how the end points for processes and services are managed, and this will impact clients of the end points. For example, let's consider a service which uses the HTTP binding and makes the cross process application call (PA1 - PA2) as shown in Figure 1. The URL for the HTTP service is formed as follows:

[http host address][Context root][operation specific portion of context path]
[http://myhost:9080][/ProviderWeb/ChequingImplExport][/operation1]

If we add a process application and version then we have a URL as follows:

[http://myhost:9080][/PA2-1.0.0-ProviderWeb/ChequingImplExport][/operation1]

When the default naming convention is followed then the URL will be automatically renamed on application installation. This ensures that all SCA intra-process application calls will work correctly. For inter-process application calls, the export binding will be updated on application install, but not the client. After deploying the process application, update the client bindings using the administrative console.

If the default naming convention is not followed then the URL must be updated manually.

Endpoint administration with different bindings

Binding type	Endpoint administration
SCA	Intra-process application: none Inter-process application: Need to update the client specifying the version of the provider to target
Inter-process application or external application calls
Web Service	SOAP/HTTP endpoint must be renamed to be unique between versions of the process application. SOAP/JMS destination queue must be renamed to be unique between versions of the process application. Renaming can occur in the authoring environment or post installation using the administrative console.
HTTP	Endpoint URL must be renamed to be unique between versions of the process application. Renaming can occur in the authoring environment or post installation from the administrative console.
JMS	Specified JNDI resources, or Resources created on application installation with version mangle names. Need to update the client (with the JNDI name of the request destination).
Generic JMS	Specified JNDI resources in authoring environment, or Resources created on deployment with version mangle names. Update resources in authoring environment or post installation using the administrative console.
MQ	Specified JNDI resources in authoring environment, or Resources created on deployment with version mangle names. Update resources in authoring environment or post installation using the administrative console.
MQ JMS	Specified JNDI resources in authoring environment, or Resources created on deployment with version mangle names. Update resources in authoring environment or post installation using the administrative console.
EIS	Normal administration for an external application. Can be specified at author time or administrative console.
EJB	Normal administration for an application.

Resource creation by binding

The messaging and EIS bindings support two methods of specifying an endpoint:

• You can define the properties in the binding and the resource will be created on deployment.

• You can specify the JNDI name of the resource on the server.

This applies for resources like a ConnectionFactory, ActivationSpec, and Destination.

Other resources, such as a Java Authentication and Authorization Service (JAAS) resource or a data source, need to be created in the administrative console. The name of the resource is then specified in the binding.

When you provide connectivity to a service using the messaging bindings, you need to be careful.

1. To support multiple clients, the provider specifies the request destination and the client specifies the response destination.

2. For co-deployment, unique destinations are required for request and response.

3. For Generic JMS, MQ, and MQ JMS bindings, there is actually a level of indirection. For example, the JNDI resource in the administrative console refers to a Queue manager and Queue defined in WebSphere MQ. The Queue must be unique.

EIS bindings are used to access a service in an external application or be notified of an event in an external application. They are not used for inter-process application or intra-process application calls.

23. Limitations when working with process applications and toolkits

Differences between the modules and libraries created in your workspace and the process applications and toolkits that originated in the Process Center repository mean there are some limitations when you develop business processes in this collaborative environment.

The following sections group the limitations as follows:

• Limitations for the definition of an Advanced Integration Service in IBM Process Designer and its implementation in IBM Integration Designer
• Limitations on the configuration of process applications and toolkits
• Limitations when creating a Business Process Definition or an Advanced Integration Service

Limitations for the definition of an Advanced Integration Service in Process Designer and its implementation in IBM Integration Designer

• An Advanced Integration Service and its interface (WSDL) must reside together in the same process application or toolkit.
• IBM recommends that only one request-response operation be defined in the Web Services Description Language (WSDL) file associated with an Advanced Integration Service. Using one request-response operation per interface reduces the risk of generating multiple WSDL files in Process Designer when changes occur.
• A binding style specifies how a service is bound to a messaging protocol. Binding style is sometimes called the WSDL style or encodingstyle. An interface for an Advanced Integration Service must be of the document literal wrapped binding style.
• An SCA export should have only one interface. As discussed in other limitations, using one interface and one operation reduces the risk of generating multiple WSDL files in Process Designer when changes occur.
• An operation parameter must be a valid Java name.
• The following types are not supported: anySimpleType, QName.
• The runtime validation is not enforced for XSD enumeration, duration, hexBinary, base64binary types, or ID or IDREF references in any part of the system.
• A list of XSD / WSDL restrictions as defined in XML constructs not supported.

• If you import a process application and later refresh it with updates from the Process Center, you may see attributes marked deleted and added instead of an expected delta change such as a renamed attribute. These changes are from the Process Center and are caused by the differences between the Process Designer and Integration Designer programming models.

• You cannot use full-length Latin and half-width Katakana characters in SCA component names (eg BPEL or mediation flow component) in Integration Designer even though these characters are permitted in Process Designer and the Process Center. This restriction is an XML standard restriction on XML names.

• To use a WebSphere adapter in a stand-alone resource adapter configuration, restart the Process Center or Process Server after installation of the adapter before you can deploy an application from the Process Center that uses the adapter.

• You can make a service in Integration Designer available to Process Designer. This approach of starting an Advanced Integration Service in Integration Designer is known as a bottom-up approach. Should you create an interface with multiple operations and a business programmer makes changes to any of them in Process Designer then multiple files will be generated.

  To prevent this error, place the interfaces and data types in a toolkit with read-only access for the business programmer. This recommendation is discussed in Best practices when using IBM Integration Designer and Process Designer together. Alternately, use only one operation for each interface.

• In a bottom-up approach as described previously, an Advanced Integration Service parameter that is typed to a wrapped array created in Integration Designer will be represented in Process Designer as a list type if the following conditions are true: the wrapped array has only one child element; the maxOccurs indicator element has a value of unbounded; there are no attributes; and the element has an ArrayOf type name.

• If a Process Designer user modifies a business object (or XSD) the business object inProcess Designer will get regenerated based on the business object model definition. The result is the business object you published may not be the business object you receive.

• If you use an element reference, be aware that once the Process Designer user modifies the element reference, the global element will become a global type and the references will be broken since the global element is no longer present.

Limitations on the configuration of process applications and toolkits

• Modules and library names must be unique in a process application.
• When you disassociate a default project ( the default module: PA_Implementation or the default library: PA_Library), you cannot then reassociate the same default project that you have disassociated. To associate the disassociated default project back to the Process Center, you must rename the project before you can associate it to the same process application or toolkit in the Process Center. If a process application does not have a default project associated to it ( the default module: PA_Implementation or the default library: PA_Library), when you open that process application in your workspace, a default project is automatically created.
• When a toolkit is shared with another Process Center, you can open the tip of the toolkit and the tip of the process application in the same workspace. Before using the refresh and publish action, however, you must right-click the toolkit and change the snapshot version to the snapshot version the process application depends upon.
• Testing process applications on the Process Center server using the integration test client requires that an HTTP connection be available. When only an HTTPS connection is available, the deployment manager connection information cannot be obtained and testing a process application will fail.

Limitations when creating a Business Process Definition or an Advanced Integration Service

• When you create a Business Process Definition (BPD) or an Advanced Integration Service (AIS) for the same process application or toolkit, you need to make sure the BPD and the AIS both have a unique name so the WSDL they each generate will also have a unique name. This makes sure that both WSDL's are integrated to your project. This applies to the Advanced edition only.

+

Search Tips   |   Advanced Search