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:
|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:
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.
Content-based Routing (the first Choice) element is used route the request to 4 different processing elements:
- Error – there are missing or invalid query parameters in the REST request
- Both sapem and startrack SOAP services need to be called and their responses aggregated (using the Composed Message Processor EIP)
- Only the sapem SOAP web service needs to be invoked
- 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:
The Camel Route Diagram can be displayed in the Openshift Java Console.
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 xip.io host address something like:
In which case configure your DNS to point to Google’s whose IP Address is 188.8.131.52 and it will work.
The demo follows the use case requirements, which are:
Access sapem WSDL
Query Parameter Checking
Call SOAP Service sapem only
call SOAP Service startrack only
call SOAP Service sapem and SOAP Service startrack and aggregate responses from both systems
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.
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.