WPS: Error flows in Mediations WID 7.5

Error flows :

An error flow is a new type of mediation flow that catches all unhandled errors. A mediation flow generated using IBM Integration Designer V7.5 automatically includes a single error flow within each operation, as shown below. Mediation flows that are migrated to use the text-based mediation flow format will have an empty error flow added to the operation.


The error flow consists of an Error Input node, the entry point to the flow, an Input Response node for optionally returning a response, and an Input Fault node for each modelled fault, if defined. The flow can contain any combination of mediation primitives and can be used to log errors, handle errors externally through the use of Service Invoke primitive, or end the flow with an unmodelled fault by using a fail primitive. The error flow is invoked when an unwired fail terminal is encountered in a request or response flow, including the fail terminal on the Callout Response node. If an unwired fail terminal is encountered in the error flow itself, or if the error flow is not wired, then the flow will fail with an unmodelled fault. After the processing of the error flow is complete, the request or response flow is abandoned and no further processing occurs. A response or fault returned by the error flow replaces any response previously created by other flows.

WPS : Service Invoke mediation primitive enhancements in WID 7.5

 Service Invoke mediation primitive :    A new mode of operation called Message Enrichment Mode has been added to the Service Invoke mediation primitive to enable service invoke requests to be constructed from parts of the SMO and responses to be easily merged back into the SMO being processed in the mediation flow. So in this way, the same SMO passes through the Service Invoke and is augmented with information from the response to the service invoke. This process removes the need for additional transformation logic before and after the service invoke primitive, which in previous releases was required to achieve this scenario.

For example, imagine a scenario where a back-end service is used to augment a message with a customer's detailed address information. A single service invoke primitive can now construct a new request message containing the customer id information and send it to a back-end service. It can then merge the completed address in the response back into the SMO at a specific point, and flow the whole message on for further processing in the flow. In this way, the Service Invoke primitive can now be chained together to simply merge input from several services. Transport headers can be optionally propagated from the SMO into the request for the Service Invoke and can be merged back into the SMO from the response.

             When the Service Invoke mediation primitive is added to the canvas, a dialog opens to ask you to configure the reference operation to be used to invoke the back-end service. At this point, you can select the new Message Enrichment Mode. This decision will change the configuration required for the Service Invoke primitive and can be reversed later only by deleting and recreating the primitive on the canvas.

Select Message Enrichment Mode when creating a Service Invoke primitive

Once Message Enrichment Mode is selected and the Service Invoke primitive is created and wired into the flow, new configuration parameters appear in the Properties panel of the primitive. For each input, output, or fault part of the interface of the reference operation used for the Service Invoke, you must select an XPath expression to identify its mapping to the SMO flowing through the primitive:

Defining the input and output arguments

In addition to the parameter mappings, you can choose to propagate headers from the SMO into the request and also to propagate headers from the response back into the SMO.