I would like to list out some of the best practices which were used in our projects. Hope it will be useful to you while designing and developing your own business process orchestration.
- Never include business logic in the ESB or BPEL.
BPEL is for orchestration and workflow. Business logic should be used in services consumed by the BPEL manager, or in the rules engine. ESB is for transformation and routing. Transformation is rearranging the format of data in a message to a different message format. It should not be manipulating data. Use of Domain Value Mapping (DVM) is acceptable.
- Use WSIF with Java/EJB if you want to maintain a transaction and improve performance
Java/EJB can be invoked using WSIF framework. Invoking Java resources is usually faster than invoking Web services. EJB remote interfaces are accessed through RMI-IIOP where as web services use SOAP, which is less efficient than binary IIOP. WSIF supports automatic propagation of transactional context between involved Java resources using the XA interface. So in case of an exception entire transaction will be rolled back. In case you are not using EJBs with WSIF you would have to manually define compensation handlers for each Web service.
- Use canonical data models for transformation
All messages on the bus are converted to a common data model which will help in reducing the overall number of maps. Advantage is that the respective application owners only need to know about 2 data models: their own and canonical .New destination can be added with minimal changes
- Use dynamic binding of partner link for complex business scenarios with multiple external systems
In large systems business processes are complex. They interact with multiple external services and define multiple partner links, and some of these partner links might not be known at design time. As a result, all potential callouts and logic for deciding which partner links to use must be built inside the business process itself. Instead of having separate partner links for all the similar external systems we can have a partner link and endpoint url will be assigned at runtime. Dynamic binding allows the developer to add new services through configuration or run-time inputs. Dynamic binding of partner links allows for modularization of code and run-time binding between processes
- Always set nonBlockingInvoke BPEL Property if you are having parallel flows
This property can improve performance when executing multiple branches of a flow or flowN activity. By default, Oracle BPEL Process Manager executes in a single thread, executing the branches sequentially instead of in parallel. When this property is set to true, the process manager creates a new thread to perform each branch’s invoke activity in parallel. This setting can be configured for each partner link in the bpel.xml file. This property is applicable to both durable and transient processes.
- Minimize creating/updating/copying of large variable
Always try to minimize the use of large variables in payload which will help in improving the performance.
- For BPEL Processes always use ESB to Virtualize Services Endpoints
The practice would allow adding newer destinations without adding transformation service in orchestration layer. The changes in data format of any destination system will not trigger changes in orchestration layer and thus regression testing can be avoided.
- Avoid large FlowN
A large FlowN will hang up other threads since all other threads will wait till large or time consuming flow is finished.
Routing services and transformation services are tightly coupled in Oracle's ESB. Unified routing would require regression testing for all end points even if only 1 transformation changed. Separation of routing services allows for independent development and testing, reducing amount of centralized administration and overhead. Separation of routing services allows processes to be exposed as unique services (have own WSDL) for reuse.
- Avoid large While loop
Always try to spend least time inside a loop. Try to avoid unnecessary loops as far as possible.
- Create customized ant task to deploy the Webservices, BPEL and ESB processes to multiple environment with different configuration values
This practice would allow building and deploying process independent of JDeveloper. It will help in easy movement of BPEL and ESB processes from one environment to another. It gives flexibility to change parameters (inbound file path, outbound file path, topic names, etc.) during deployment phase.