Design Considerations

When configuring components in different contexts to communicate with one another, there are several areas you need to consider:

The Dialect used in the component you first invoke will be the one used in every subsequent component. You cannot switch dialects when going from one context to another.
Browser Controlled History Handling is not supported for Cross-Context Flows and the Build Tool will turn this feature off if Cross-Context Flows are enabled.
The domain name, localhost, cannot be used for Cross-Context Flows. This includes both the Load Module mapping that is done in the Build Tool and WindowManagerCfgUserExit, as well as the actual initiating URL address entered in the browser.
A procedure step that is invoked through a Procedure Step Use may not flow to another procedure step that causes a display.
Database transactions cannot be extended across multiple contexts. Each flow across context boundaries will cause a new transaction to be created for the duration of that procedure step. In the case of a USE, the current transaction is suspended and a new transaction is created for the duration of the called procedure step. Upon return, the original transaction is continued. Care must be taken to avoid deadlock conditions when processing USEd procedure steps.

Following are examples you can consider to reduce the performance degradation you will experience when using Cross Context Flows:

Applications utilizing Cross Context Flows will be slower than those that stay within the same context. You may consider using Cross Context Flows during your Development cycle and for Production, package your application in a single context.
Cross Context Flows between separate applications deployed on the same local application server system are likely to perform better than those that are deployed on separate systems. This is because the data will not be transferred across the network.
The larger the sizes of the views that are passed across contexts, the bigger the negative impact on performance will be. Consider reducing the sizes of views that will be transmitted across contexts.
Chaining Link flows will cause the amount of information passed between each context to grow. For example, doing Links from PStepA to PStepB to PStepC will cause the session information for both the PStepA and PStepB to be passed along to the context in which PStepC is located. Avoid Chaining Links across contexts.
If possible, use Transfers instead of Links when flowing across contexts.
Configure the Application Server's JMS to cache the session messages in memory.