Design Pattern: How to Create a Web Service Mashup/Composite Call with an Aggregated Response

Document created by ndorairaj on Jul 8, 2015Last modified by Adam Arrowsmith on May 20, 2016
Version 6Show Document
  • View in full screen mode

This article describes an advanced technique for performing multiple connector calls in parallel and returning an aggregated response typically within the context of a web service mashup or composite call.

 

 

Use Case

A published web service needs to retrieve information from a variety of backend systems and assemble a single consolidated response. The calls to the backend systems are independent and should be performed in parallel to minimize execution time. In other words, you want to do DIFFERENT things with the SAME document at the same time. This differs from normal Flow Control with parallel threading which does the SAME thing with DIFFERENT documents at the same time.

 

Approach

  1. Publish web service that receives a single request message.

  2. Use a branch step in a subprocess to “copy” the document as many times as backend systems. The subprocess is important to return all the documents as a single group.

  3. Assign a different dynamic document property value to each document “copy”.

  4. Use a Flow Control to spawn as many threads as backend systems. Each thread will receive one document.

  5. Route by the dynamic document property to a particular backend system/subprocess.

  6. Each backend system subprocess performs its lookup and stores results in a document cache.

  7. Once all threads are complete, in the top-level process use a map to retrieve the results from the document caches and map to a single response message.

Implementation

Detailed below is a suggested implementation approach.

 

Main Process

This service:

  1. Receives the request payload. 
  2. Invokes the Multi-Thread request process which triggers the concurrent backend application calls that store results in document cache(s). 
  3. Assembles the consolidated response to return to client. In the above example the results from the two systems (i.e. employee and department) have been stored in separate document caches within the respective backend application processes. The cached documents are retrieved and mapped to the consolidated response format. 

 

Multi-thread Request and Parallel Flow Control

 

 

 

 

 

Big idea: You must coordinate the following: backend systems = routes = parallel threads = number of document copies. This process:

  1. Generate multiple copies of the original request, one per application. This is done in a subprocess to be able to return all documents as one group to the calling process.       

    1. Remember the Return Document steps waits for all paths to complete before returning.      

  2. Each document copy is “tagged” with a dynamic document property with values “1”, “2”, “3”, etc. 

  3. Configure Flow Control with as many threads as documents. Each thread will get one document. 

  4. Route by the dynamic document property to a different end application/subprocess.      

    1. Note: In each thread, the given document will be routed down a different path.      

  5. Invoke the end application process in parallel. 

  6. Nothing is returned to the calling process. Once all threads have completed, control will return to the calling process. 

 

Backend System Process

 

 

In the called process:

  • Invoke the backend system (in this case a DB) with the required parameters obtained from the input XML. In this case it would be the empid. 
  • Map the response to a standard format and store it in a document cache. Ensure the document cache is a value that is available on the original request so it can be retrieved when composing the final response. 

 

Usage Considerations

  • Increasing the number of parallel calls would cause an impact on performance. 
  • Similarly retrieving a large amount of data or endpoint latency would have an impact on performance. The overall process will only be as fast as the slowest backend system lookup. 
  • Error handling of non-availability and exceptions on any one of those endpoints needs to be built in as per requirements.
6 people found this helpful

Attachments

    Outcomes