Camel Route Design View

A Reusable Fuse Integration Services 2.0 Demo


Recently a potential customer wants to see how FIS 2.0-based services and API Management can work together to replace the integration platform he is currently using. The customer has asked another vendor to do a PoC on AWS. Red Hat has been invited to do the same but called it a demo. Consequently, we set up Openshift on Google Cloud Platform for the demo. In this article, I am going to describe only the FIS implementation of the use case mandated by the customer. The FIS 2.0 and 3Scale integration is covered in another article.


The mandated integration use case, which is in production implemented using an outdated integration platform, is as follows:

Create a REST service Service which takes query parameters. Depending on the product idåentifier(s) specified, it decides whether to:

  • query parameter checking
  • call SOAP Service A only
  • call SOAP Service B only
  • call SOAP Service A and SOAP Service B and aggregate responses from both systems
  • response filtering


The table below describes the query parameters:

Query Parameter Mandatory Description
product_ids Yes Can be either STR-ON, STR-ARL, EAPRCEL-REG or EPRCEL-EXP. The first 2 are handled by the startrack SOAP web service while the others are serviced by the sapem SOAP web service
features No Can specify one or more filters separated by comma. If features are specified, only those features specified will be returned to the request. Features include: IDOD, ATL, TIMESLOTS, WKEND and COLLECT
from_postcode Yes 4 digit postcode
to_postcode Yes 4 digit postcode
arrival_date Yes A date in YYYY-MM-DD format


All services are to be implemented using FIS 2.0 and deployed on Openshift in public cloud.


A total of 3 Spring Boot-based SOAP and REST services are built using FIS 2.0 and deployed on Openshift. They are:

  • SOAP Service A (sapem) is a SOAP web service whose WSDL and source code can be found at here.
  • SOAP Service B (startrack) is a SOAP web service whose WSDL and source code can be found at here.
  • The REST service (products) implements the use case in the previous section. Its source code can be found at here.

In order to implement the mandated use case in the REST service, 2 Enterprise Integration Patterns, namely, Content-based Routing and Composed Message Processor were used. They are described in the following diagrams:

EIP - Content Based Router
EIP – Content Based Router
EIP - Composed Message Processor
EIP – Composed Message Processor

The sapem SOAP Web Service

For simplicity, sapem SOAP web service has been created using a contract-last approach as this is not what the client is interested in. The client is interested in using FIS to provide a REST service “products” which orchestrates the retrieval of info from either or both SOAP web services. Java code was written first and the WSDL was generated automatically from the code. The project was created using the FIS maven archetype: spring-boot-cxf-jaxws-archetype. Refer to article “Experiment with FIS 2.0 with the Absolute Minimum Setup” for setting up the FIS maven archetype in JBoss Developer Studio. The working example that comes with the generated project source code was modified to to implement the sapem service which returns canned messages based om the product identifier(s). You can find out what this service does by either looking at the generated WSDL or the source code which is available in Github.

The startrack SOAP Web Service

The approach used here is exactly the same as for the sapem service.

The products REST Service

This is the bread and butter of the FIS demo. As outlined earlier, 2 EIPs namely, Content-based Routing and Composed Message Processor, were used. If you look at the Camel Route diagram in JBDS and mentally rotate it 90 degrees clockwise, you will find it to be very similar to the 2 EIP diagrams shown earlier.

Design View in IDE
Design View in IDE

Content-based Routing (the first Choice) element is used route the request to 4 different processing elements:

  1. Error – there are missing or invalid query parameters in the REST request
  2. Both sapem and startrack SOAP services need to be called and their responses aggregated (using the Composed Message Processor EIP)
  3. Only the sapem SOAP web service needs to be invoked
  4. Only the startrack SOAP web service needs to be invoked

The Composed Message Processor EIP is used in the case where both the sapem and startrack SOAP services have to be invoked. It uses a Camel splitter and an Aggregation Strategy to split the request into 2 and later aggregated the responses into 1. Also note that data transformation has to be performed just before and after the invocation of either the sapem or startrack SOAP services. The data transformation, filtering and query parameter checking implementation are all in the Bean named utilBean.


Deployment to Openshift

After the demo to the customer, the Openshift instance running of GCP has been brought down. Consequently, all the screenshots that you are going to see in subsequent sections are taken from my local Openshift environment running on my laptop. To build and deploy the 3 services to the Openshift environment, follow the Binary S2I workflow described in my other article: “Experiment with FIS 2.0 with the Absolute Minimum Setup”. I created 3 projects to deploy the 3 services, namely, sapßem, startrack and products.

Note that the cxfEndpoints in the camel-context.xml needs to be changed to point to the new service/route created on your local Openshift for sapem and startrack and not:


Unlike the simple Camel application in my previous article, all the 3 services need to be accessed externally which means a route has to be set up for all 3 services. The following shows the route created by sapem:

Set up sapem route
Set up sapem route

The Camel Route Diagram can be displayed in the Openshift Java Console.

Java Console Diagram
Java Console Diagram

If you are experimenting with the deployment at home on your laptop and you are having problem accessing the 3 services running on Openshift, the most likely issue is that your DNS cannot resolve the host address something like:

In which case configure your DNS to point to Google’s whose IP Address is and it will work.


The demo follows the use case requirements, which are:

Access sapem WSDL

sapem wsdl
sapem wsdl

Query Parameter Checking,STR-ARL&from_postcode=3000&to_postcode=2000&arrival_date=2016-06-30&features=ABC

Parameter Error Detected
Parameter Error Detected

Call SOAP Service sapem only,EPARCEL-EXP&from_postcode=3000&to_postcode=2000&arrival_date=2016-06-30

Invoke sapem Only
Invoke sapem Only

call SOAP Service startrack only,STR-ARL&from_postcode=3000&to_postcode=2000&arrival_date=2016-06-30

Invoke startrack Only
Invoke startrack Only

call SOAP Service sapem and SOAP Service startrack and aggregate responses from both systems,STR-ARL,EPARCEL-REG,EPARCEL-EXP&from_postcode=3000&to_postcode=2000&arrival_date=2016-06-30

Invoke Both Services
Invoke Both Services

Response Filtering,STR-ARL,EPARCEL-REG,EPARCEL-EXP&from_postcode=3000&to_postcode=2000&arrival_date=2016-06-30&features=COLLECT

Note that the difference between this command and the previous one is the inclusion of the ‘features’ parameter which filters out all but the ones with the ‘COLLECT’ feature in the response.

Filter Ouput
Filter Ouput

Here is a video on Openshift deployment:


If your customer does not mandate specific use cases for a FIS 2.0 demo or you just need to demo a non-trivial FIS 2.0 application to your customer, you are welcome to use this demo. The complete source code can be found in Github.