One of the new features in Service Bus 12c is the ability to use pipeline templates. Usually the Oracle Service Bus pipelines in an environment have many common steps. Think of the re-use of logging, error handling, alerts and pattern + naming convention for your stages. In practice with OSB 11g we often used a “template” or existing OSB project which we then copied and modified. With the “clone” option of 12c this task is already easier, but the use of pipeline templates is even better. Since templates and concrete pipelines (generated pipelines from a template) remain linked we can update our services easier with new insights. For example, when you want to change your default logging or fault handling behavior.
- How to create a Service Bus 12c pipeline template
- How to generate and use a concrete pipeline from a template
- How to customize your Service Bus 12c pipeline templates
To use pipeline templates to their fullest potential we can customize them to our own needs. For this we have multiple options.
The essential configuration of most actions can be left empty in the template without any problem. As soon as they are implemented in concrete pipelines the actions there will come into an ERROR state. The example below shows the Routing which is empty in the pipeline template. When developing the concrete pipelines we can then easily set the correct business service.
Many actions, like Validate, allow us to use generic configuration of the Location instead of specific elements from the service datamodel. By using generic configuration as ./* we can tell the Validate action to validate the 1st element in the SOAP body. Which normally would be your getMessageRequest or getMessageResponse element. The correct element and schema to validate against should still be selected in the concrete pipeline.
Unlike most actions, the problem with the Replace action seems that when you leave the XSLT or XQuery of choice empty, the template will turn into an error state. To prevent this from happening I use a dummy XQuery file in my CommonObjects project and assign it from all Replace actions I use for transformation of messages..
We can set each individual action in our template to a “locked” state. With this preventing the developer of the concrete pipeline to change certain locked logic of the service. This is quite usefull for default logging and fault handling you want to enforce in your services. Right-click on each specific action you want to lock and choose “Lock Action”. Sadly there is no graphical representation to quickly show you which actions are locked.
Using template placeholders
We can use template placeholders to allow developers using the template to customize the concrete pipeline to the extend that we determine in the template. We can allow customization of unlimited stages, nodes and route, but in most cases you will probably use the most strict placeholder “Actions”. In the example below we show a stageEnrich which allows the developer to add unlimited amount of actions in this stage. Actions like Service Callouts, Transforms, Logging, etc to make sure we can extend our service. With this, creating enough flexibility for the developer to customize the logic for the concrete pipeline, without changing the default we want to enforce for logging, error handling, etc.
- Oracle: Working with Pipeline Templates