Orchestration Response Handlers enable business rules / logic to be applied to the flow and based on those rules the transaction flow can take different paths or actions can be triggered in the flows to ultimately conclude with the ‘Response’ to the Initiating System.

How do response handlers work?

Handlers can be added to any Inbound API Request or Response or any downstream system Response.

• A Handler on an Inbound API Request could for example trigger the routing of the request to another Inbound API on the same GLU.Engine.
• A Handler on an Inbound API Response could trigger the flow to be re-routed
• A Handler on an API response could based on a parameter matching a certain value overwrite the parameter with another value.
  

A Handler on the Response to an outbound Connector call is the most widely used mechanism for orchestrating your flows.

Within the Orchestration Manager, Handlers can be configured based on response Content, HTTP Status Codes or response conditions. When the handler conditions specified in the handler are met, the defined Handler Action will be triggered. The appropriate configuration box is displayed depending on the action specified.

The Response Handler can be used to end a transaction or result in a different outcome or Response to the Initiating System.

Handler Conditions

Handlers can be configured to run based on:

• Parameter values
  
• HTTP Status Codes
  
• Expressions – used to trigger the processing of a Expression in a flow
  
• Or ‘none’ – if you just want to trigger a routing event at a point in the flow use the ‘None’ category for you Handler.
  

Important notes on handlers: 

• Handlers are always executed in order first to last, so ensure your logic handlers are ordered correctly.
  
• The value in the condition cannot contain a function or formula. If required, use a Derived Parameter to apply a function or formula, then reference the Derived Parameter in the Handler Value.
  
• Note that if for example you have a set of 3 status codes all of which should result in the same handler condition being applied, you can list all three codes in the ‘Value’ field e.g. 1000, 1001, 1002

Parameter Handler

If the Parameter specified via the ‘Name’ dropdown box passes the comparison check (or other boolean operation) specified by the ‘Condition’ dropdown box, it’ll trigger the ‘Action’.

HTTP Status Codes

The GLU Engine needs to specifically be told to handle unsuccessful HTTP status codes (e.g. 400, 401, 500 etc). This is done by adding a status codes handler. Without this handler, the GLU Engine is unable to unmarshall the response payload. Ensure that you create the required HTTP status code handlers in order to orchestrate or unmarshall.

None Handler

A ‘none’ handler means that no triggering event, code or parameter value needs to be present but that the handler will ALWAYS be executed.

Handler Action Types

Route To

Routes the request to a specific flow code.

Send to Many Routes

Routes all requests to the specified flow codes.

• Parallel Processing: If enabled then sending messages to the recipients occurs concurrently. Note the caller thread will still wait until all messages have been fully processed before it continues. It’s only the sending and processing the replies from the recipients which happens concurrently.
  
• Stop On Exception: If checked Requests will fail if there’s an exception on any of the flow codes. In all situations, the recipient list will stop further processing. This is the same behaviour as in the pipeline, which is used by the routing engine. The default behaviour is to not stop but continue processing till the end.
  
• Timeout: Sets a total timeout specified in ,milliseconds, when using parallel processing. If the Recipient List hasn’t been able to send and process all replies within the given timeframe, then the timeout triggers and the Recipient List breaks out and continues.
  

Stop Process

This forces the process to stop and the message gets processed back through the Response Manager. Either the Stop Process can trigger a ‘successful’ response back, alternatively, it can trigger an error template. The error response is comprised on an ‘Error Code’ and an optional ‘Error Message’ describing the error in detail. The error code and error response values will be mapped into the parameter values are that are specified as the response parameters as below.

Overwrite Parameter

‘Overwrite Parameter’ Action will always take place at the step in the flow at which the Handler resides BEFORE any other Handler rules are applied such as a ‘ROUTE TO’ redirection handler. This means that even if the sequence of Handlers has ROUTE TO handlers pre-ceding ‘OVERWRITE’ handlers, the ‘OVERWRITE’ handlers will always be run and only thereafter will the ‘ROUTE TO’ handlers be run – in the order in which they are placed in the list of Handlers (top-down).

The parameter can be overwritten with a value or with other parameter, below some examples:

• Overwrite parameter with a value, e.g. text: HelloWorld or Int: 123 ..etc
  
• Overwrite parameter with GLU static parameter, e.g. ${GLUstaticParam}
  
• Overwrite parameter with other parameter, e.g. ${otherParam}
  
• Overwrite parameter with derived parameter,e.g. ${derivedParam}