Top 10 areas to address before taking Oracle BPEL Process Manager 10.1.3 to a Production Implementation
Arvind Jain
5th July 2007
1) Version Management (Design Time)
When we are choosing a Source Safe System or Version Control system for Business Processes the consideration are quite different than choosing a Source Safe System or Version Control system for Java, C++ code components. The average user / designer of Business processes is not CODE savvy, they cannot be expected to manually merge code (*.bpel files or *.wsdl files for example). BPEL PM lacks in Design time version management of Business Processes using the jDeveloper IDE. What is needed is a Process Based Development and Merge environment. We need Visibility into Process Repository. So the requirements are different from that of a Component based repository. Consider using a good BPMN / BPA tool.
2) Version Governance (Run Time)
While BPEL PM can maintain version number for deployed BPEL processes, it is still left to an administrator or a Business Analyst to decide which process version will be active at a given point in time and what will be the naming, versioning standard. Since every deployed BPEL Process is a service, so it becomes critical to apply SOA governance methodology to control various deployed and running BPEL Processes.
3) SOAP over JMS (over SSL)
Most of the big corporation and multinationals have policies which restrict use of HTTP traffic from outside world to inside intranet. Moreover they have policies which require the use of a Messaging Layer or an ESB as a Service Intermediatory for persistence, logging, security and compliance reasons. BPEL PM support for bi directional SSL enabled JMS communication is not out of box. It needs to be tried and tested out within your organization and workarounds needs to be implemented.
4) Authentication & Authorization - Integration with LDAP / Active Directory
SOA governance requires authentication and authorization for service access based on a corporate repository and roles defined within them. This is also critical for BPEL Human Workflow (HWF). Make sure to do a small Pilot / POC for integration with your corporate identity repository before taking BPEL PM to production.
SOA governance requires authentication and authorization for service access based on a corporate repository and roles defined within them. This is also critical for BPEL Human Workflow (HWF). Make sure to do a small Pilot / POC for integration with your corporate identity repository before taking BPEL PM to production.
5) Integration with Rules Engine
BPEL should be used for Orchestration only and not for coding programming logic or hard coded rules. Hence it is important to have a separate Rules Engine. Many rules engine available in Market support Java facts and BPEL Engine Being a Java Engine should integrate out of the Box with these. But some rules engine have the limitation that they can take only XML facts, so it is an overhead to go from Java to XML so as to use XML facts and then marshal back to Java. So make sure that you have sorted out Integration with Rules Engine prior to BPEL production implementation.
BPEL should be used for Orchestration only and not for coding programming logic or hard coded rules. Hence it is important to have a separate Rules Engine. Many rules engine available in Market support Java facts and BPEL Engine Being a Java Engine should integrate out of the Box with these. But some rules engine have the limitation that they can take only XML facts, so it is an overhead to go from Java to XML so as to use XML facts and then marshal back to Java. So make sure that you have sorted out Integration with Rules Engine prior to BPEL production implementation.
6) Implementation Architecture
BPEL processes and projects can and will expand to occupy all available resources within your organization. These business processes are pretty visible processes within a company and have strict SLAs to meet. Make sure you have a proven and tested reference architecture for Clustering, High Availability and Disaster recovery. There has to be a provisioning process, deployment process and Process Life cycle governance methodology in place before you can fire up all engines in a production environment.
BPEL processes and projects can and will expand to occupy all available resources within your organization. These business processes are pretty visible processes within a company and have strict SLAs to meet. Make sure you have a proven and tested reference architecture for Clustering, High Availability and Disaster recovery. There has to be a provisioning process, deployment process and Process Life cycle governance methodology in place before you can fire up all engines in a production environment.
7) Throughput Consideration
BPEL PM by nature is an interpretation engine and hence there is a performance hit when running long running processes and doing heavy transformations. Plan on doing some stress and load testing on the servers running your Business Processes to get a Ball Park estimate of what is the end to end processing time and how much load can be taken by the BPEL server. Specifically do a capacity planning based on results from these pilot load and stress tests.
BPEL PM by nature is an interpretation engine and hence there is a performance hit when running long running processes and doing heavy transformations. Plan on doing some stress and load testing on the servers running your Business Processes to get a Ball Park estimate of what is the end to end processing time and how much load can be taken by the BPEL server. Specifically do a capacity planning based on results from these pilot load and stress tests.
8) Design of BPEL Process (Payload Size, BPEL Variables - Pass by Reference or by Value)
Designing a Business Process is more of an art than a science and the same holds for BPEL Business Processes. It is important to understand what will be best practices in your organization in terms of Payload size and length of various Processes and how they are orchestrated. Are you passing across big XML payloads which can be avoided by changing the process and using a technique called as passing by reference? Will that also make your process more efficient and create true Business Services from these processes? Give a consideration to these and spend some white boarding sessions with Business and IT Analysts before creating a BPEL process.
Designing a Business Process is more of an art than a science and the same holds for BPEL Business Processes. It is important to understand what will be best practices in your organization in terms of Payload size and length of various Processes and how they are orchestrated. Are you passing across big XML payloads which can be avoided by changing the process and using a technique called as passing by reference? Will that also make your process more efficient and create true Business Services from these processes? Give a consideration to these and spend some white boarding sessions with Business and IT Analysts before creating a BPEL process.
9) Schema Consideration - Canonical Data Model & Minimal Transformations
The most cost and resource intensive step in any Integration or Process Orchestration scenario is Transformations. Especially in an orchestration engine like BPEL PM the XML payload goes through multiple massaging steps. If you can design your process flow in such a way that there is minimal of these steps then it will improve the performance of Business Process end 2 end. Also it is a best practice to have an enterprise wide canonical data model derived from some industry wide standard like OASIS, Rosettanet, ebXML etc
The most cost and resource intensive step in any Integration or Process Orchestration scenario is Transformations. Especially in an orchestration engine like BPEL PM the XML payload goes through multiple massaging steps. If you can design your process flow in such a way that there is minimal of these steps then it will improve the performance of Business Process end 2 end. Also it is a best practice to have an enterprise wide canonical data model derived from some industry wide standard like OASIS, Rosettanet, ebXML etc
10) Administration - Multiple BPEL Console, Central HWF Server, Customized UI or use existing UI?
BPEL PM is easy to use and makes process orchestration almost a zero coding activity. Also it is pretty easy to learn and hence there is suddenly a bunch of BPEL processes deployed and a bunch of BPEL developers in enterprise once the floodgates are opened.
BPEL PM is easy to use and makes process orchestration almost a zero coding activity. Also it is pretty easy to learn and hence there is suddenly a bunch of BPEL processes deployed and a bunch of BPEL developers in enterprise once the floodgates are opened.
It is very critical for an enterprise scale deployment to figure out ways to Provision BPEL Server Instances and to give selective access to BPEL Console to relevant developers. BPEL console is a powerful tool and there is not much of a role based security functionality in that except for the concept of domains. Options are to create your own Administration / Console UI using the BPEL Server API’s or to have a BPEL Administrator take care of such requests.
BPEL PM comes with a built in Human Workflow Server (HWF) but in an enterprise you might want to have a centralized HWF server. All these need to be given though to before putting BPEL PM into a production environment.
