These processes were architected & designed under following business and technical constraints and conditions:
1. Use of Oracle Fusion Middleware is mandatory.
2. Minimize the software license cost for SAAS provider and its customers.
3. Minimize development cost for SAAS provider.
4. Minimize customization cost for SAAS provider’s customers.
5. Minimize product support cost for SAAS provider and its customers.
6. Customers must be able to customize the processes.
7. With the deployment of upgraded version of process (not the BPEL Fusion Middleware upgrade), customization of customers must be preserved. Manual intervention must be minimum.
8. Processes must be designed keeping Oracle Fusion Middleware road map in sync.
So the decision on selection of Oracle Fusion Middleware was already done.
Bust still lot of architectural and design decision were to be taken.
A. The first decision was to not to use AIA framework. This decision was based on following considerations:
a. Additional license cost of AIA
b. Skills need for AIA were not available in-house and even with independent service providers. Development of skill set or getting from outside was costly in-terms of time and money.
c. AIA is pretty new kid on the block.
d. There is no clear-cut road map for AIA.
B. For processes there were two choices: BPEL PM and ESB. BPEL PM was chosen over ESB for development of processes because of:
a. Processes were quite complex and involved lot of service orchestration. So BPEL was in and ESB was out.
b. Any BPEL PM process can be registered with ESB so even if processes were developed in BPEL PM, they can be registered with ESB if required in future without any changes required in process code.
c. To reduce license cost for SAAS provider and its customers.
C. To manage Errors and Exceptions, error hospital of Oracle Fusion Middleware and especially BPEL PM. Errors & Exceptions were classified as:
a. Business
b. Application & Logic
i. Binding
ii. a
c. System
d. Miscellaneous
Retry mechanism of BPEL PM was employed to care of transient faults in IT assets like network, database, connecting systems, etc. Error & Exception Management was developed as separate collection of processes, which primarily catered to:
a. Handling of Errors & Exceptions
b. Logging of Errors & Exceptions
c. Notification of Errors & Exceptions
Individual business processes handled error & exception but Logging & Notification was completely outsourced to maximize the reuse of services across business processes.
To achieve replay of service remediation framework was developed. The options available to log and remediate errors and exceptions were:
a. JMS queue
b. Direct database store
c. Advance Queue
JMS queue was not able to win favor due to requirement of separate JMS server in enterprise, which was directly increasing investment and operational costs.
Direct database store was also not able to win positive note due to higher development & maintenance cost.
AQ was on high due to native support from Oracle Database and only one time operational cost – during first deployment: AQ enablement on database.
Compensatory services were also developed because of usage of Asynchronous processes and need to maintain transaction integrity.
D. From experience in similar products using TIBCO and SAP XI following learnings were noted:
a. Customers customize processes
b. Customers don’t like to override their customizations with introduction of newer version of processes by SAAS provider.
c. Lot of human intervention needed to preserve customization done by customers. This is error prone way.
d. Most of mapping is done in m aping where elements from source and target applications were mapped.
e. Interface definitions of source and target applications seldom changes during their lifetime. In simple language Schema of source and target message changes only when one of application changes which is rare.
To resolve these challenges two approached were evaluated:
a. Three processes based approach
To ease in handling customization by SAAS provider’s customers, each business process will be divided into three BPEL processes. For example a business process where Data flows from SAAS to Oracle eBusiness Suite, one BPEL Process will cover data fetch from and data submission to Oracle eBusiness Suite while other two will do the transformation & Mapping.
Here the idea is that in Process-2, data is mapped from SAAS Schema to eBusiness schema in the default way (SAAS Provider way). This process will deployed as separate process in BPEL Process Engine server.
The Process-3 also maps the data but it has some twist. In its mapper this process should have two input schemas (SAAS and eBusiness) and one output schema (eBusiness). The default mapping will be of one to one mapping (eBusiness to eBusiness) but client may modify as per their need.
Process -2 and Process-3 will be deployed separately and will communicate via XML. Process-2 will pass XML to process-3.
Now SAAS Provider releases second version of its product then it gives only process-1 & 2 as upgrade not the process-3. In this case client can choose not to update process-3 to preserve its customization. This approach assumes that only mapping changes from version to version not the schema.
This approach may have performance issue due to communication overhead.
b. Multiple Mapping files based approach
In this approach customer will be provided two sets of mapping. Customer will not modify Mapping-1 but Mapping-2 will be. With the new release of process, customer will retain XSL referring to Mapping-2, which will preserve his customization.
In both approaches only Mapping customizations are taken care not the changes in Schemas and upgrade in BPEL Process Manager.
The choice of approach will be decided with some performance test on the sample process.
E. Products were involving big EIS (Enterprise Information System) s and SAAS application which were serving complex business processes. Often to increase reliability and support business process are deployed different instances of EIS on the basis of geographies or business lines. So there were two possible cases:
a. n:1 scenario
b. 1:n scenario
a. n:1 scenario
In the scenario where data will be fetched from multiple Oracle eBusiness Suite and fed into single SAAS instance, multiple instances of a BPEL Process will be deployed with updated connection details for Oracle eBusiness Suite.
b. 1:n scenario
Content based routing will be achieved via switch case. To achieve 1:n (input:output systems) switch based approach is simpler and clean.
The other approach to achieve content based routing is ESB. But in ESB the targets are again defined at Design Time only. There is no way one can define target systems at deployment or run time. To reduce the number of systems involved, BPEL solution with switch case is preferred.
But option was left open to customer so if customer wishes, BPEL process can be registered at ESB and ESB based routing can be availed.
