New feature for the Pipeline for Cloud Integration: custom preprocessing exit

[alex_bundschuh]

As mentioned in my last blog post New integration packages for the Pipeline for Cloud Integration, we have deprecated the previous package  Process Integration Pipeline - Generic Integration Flows & Templates and have shipped four new packages replacing the deprecated package for supporting the Pipeline for Cloud Integration. You will notice that the previous package has the label [DEPRECATED] in its name now. No worries, you can still run the old package in a transition phase, if you run the latest update you will notice that just the name has been changed. But we encourage you to switch to the new packages, see Pipelines about how to proceed.

One more reason for switching to the new packages, besides the higher flexibility for setting up different pipelines, is that from now on we ship new features in the new packages only. One of the new features that we have lately shipped is the support for custom preprocessing. You have the option to call a custom exit integration flow without having to edit the provided generic flows. To do so, you must implement a separate integration flow that can be called at the very beginning of each generic integration flow. See Custom Preprocessing Exit.

Let me show you how to configure the custom preprocessing. You have two options, either configure it globally, which means that the custom exit integration flow is called for all of your integration scenarios, or configure it scenario-specific. You can even combine both options, having one global custom exit which is applied across all scenarios and in addition calling scenario-specific exit flows for particular scenarios only.

Global setting

To enable custom preprocessing globally, you need to configure each generic integration flow that should call the custom preprocessing flow as follows:

In the configuration, change the value of the parameter CustomXPreGlobal_Enabled from false (which is the default) to true. Furthermore, maintain the ProcessDirect endpoint of your custom exit integration flow in the parameter CustomXPreGlobal_Endpoint, by default the value is /pip/custom/preProcessing/global. You can keep it or change it to your preference. You may then create one custom integration flow for each generic integration flow of the pipeline or use one single custom integration flow across all pipeline steps depending on your requirements. See also below.

Scenario-specific setting

For scenario-specific configuration, you can define for which pipeline steps the custom exit integration flow should be called. For this, you need to add the corresponding string parameters to the scenario in the Partner Directory for which the custom preprocessing should be enabled.

Create a string parameter CustomXPreEnabled where you define the list of pipeline steps which should call the exit flow separated by pipe.

In our example in the screenshot below, we enable custom preprocessing for all pipeline steps:

• 01 stands for either the generic XI inbound processing or the generic IDoc inbound processing
• 02 corresponds to either the generic inbound processing flow or the generic integrated messaging runtime
• 04 corresponds to the generic receiver determination flow
• 05 corresponds to the generic interface determination flow
• 06 corresponds to the generic outbound processing flow

If you run through the integrated messaging runtime, which is our recommended pipeline anyway, only step numbers 01, 02, and 06 are relevant. If you only like to run the custom exit flow for the integrated messaging runtime and the generic outbound processing flow for instance, then set the value to 02|06. I think you get the point.

Furthermore, create a string parameter CustomXPreEndpoint, which points to the ProcessDirect endpoint of your custom exit integration flow. Other than for the global setting, here we only support one custom integration flow across all pipeline steps to minimize the configuration effort, but you can have a separate custom integration flow for each scenario. See how we are able to implement pipeline step specific logic below.

Because we only have one custom integration flow for each scenario, we pass the header customXPipelineStep from the generic flows to the custom flow. With this, you have the option to implement pipeline step specific logic based on this very header. You can use a copy of the template Pipeline v2 Template - Custom Exit to model your custom flow. It contains a router with routes for all pipeline steps including corresponding router conditions. To ensure that the header value is present in the custom flow, the header is part of the allowed headers settings. Furthermore, the template adds the pipeline step number to the custom header properties so that you have full transparency in the message monitor about which pipeline step called the exit flow.

From what we heard from customers, potential use cases could be to implement additional external or internal logging capabilities or to stop certain messages from sending to the receiver systems based on some conditions, e.g. maintained in the Partner Directory. So, regardless of your use case, I think with this we have increased the flexibility of the pipeline for Cloud Integration.