Code quality is very important for software development. If organization contains many young developers for BPEL, composing and maintaining coding standarts are must. If codes are written according to standarts, code reading and developing is getting easier.
As a programming language BPEL is easy to use and deploy. But there are some important points that the developers should not omit.
Except AQ Adapter, all of BPEL Projects are deployed as web services. So we should consider following keypoints are listed below.
1. Sensor Values
The main purpose of sensors’ definition in BPEL processes is the following business events such as faults and web service calls in runtime. When Fault events occured fault events are collected by BPEL, fault events is used to report other integrated systems from BPEL Platform.
2. Fault Policy
Fault Policy is a very important feature of BPEL environment. When fault policy is defined and error occurs in runtime, Bpel allows to trigger defined another environments for creating alarms.
3. Timeout
Service invocation takes time and a default timeout interval may be too long for external services. For managing service availability of SOA Suite and transaction SLA(Service Level Agreement) time, timeout policy should be defined for external web service calls.
4. MDS usage
MDS is a repository which holds common artifacts such as WSDLs, XSDs, Domain Values Maps but can also hold fault policies and event definitions.
In many big SOA applications, all the composites use the same data model (message definitions) for their service contracts. Many entities and elements are reused. Therefore we upload common artifacts to MDS and access these artifacts from MDS in the project, instead of using local copies of WSDLs and XSDs. If we don’t use MDS, if mayor part of message definitions changes then we need to update all the SOA composite projects.
MDS usage provides reusability and avoids unnecessary redundancy and also guarantees that the changes are made in only one place. Also MDS usage helps in loose coupling of service bindings & remove service dependencies.
5. DVM Usage
DVM allows you to map values used in one domain for specific field to the value used in other domain for same field. For example some domains might use the code for customerType 1 as Residential, where as the other domain can use the complete name as Residential . In these cases we can use domain value maps. Domain value maps are static. DVM is like a properties file in Java.
No code change is required if you want to change the dvm values or add new entities to your DVM. You can change the values at runtime in SOA composer.
6.Local Variable Usage
Local variables are types defined in Scope in . bpel file. They can be accessed only in the scope. At run time while executing the flow, when the scope ends the local variables no longer remain in the memory. But global variables live during executing the full bpel flow. Using local variables enables us a more effective memory usage.
7. Naming Conventions
Generating Flow names should be managed from common center. Partitions could be seperated according to mediator and flows.
When component does not contain many components, name of composite should be same name with its component.
8. Implementation
When marketplace does not belong to BPEL domain, adding omitWSA to the partnerlink allows to prevent extra headers values in the SOAP messsage to external service.
If number of transactions is greater than 100K, audit log could be closed or manuel audit could be applied.
Suna Ün Aytar, Arzu Tarımcı
İstanbul,2019