In the ESB profile of WSO2 Enterprise Integrator (WSO2 EI), this is commonly referred to as Service Chaining, where several services are integrated based on some business logic and exposed as a single, aggregated service.

In this tutorial, you send a message through the ESB profile to the back-end service using the Call mediator, instead of the Send mediator. Using the Call mediator, you can build a service chaining scenario as it allows you to specify all service invocations one after the other within a single sequence.

You then use the PayloadFactory mediator to take the response from one back-end service and change it to the format that is accepted by the other back-end service.

See the following topics for a description of the concepts that you need to know when creating ESB artifacts:

Before you begin,

Install Oracle Java SE Development Kit (JDK) version 1.8.* and set the JAVA_HOME environment variable.
Go to the product page of WSO2 Enterprise Integrator, select Other Installation Options, and download the Binary distribution. Extract the ZIP file of the binary. This will be your <EI_HOME> directory.
Select and download the relevant WSO2 Integration Studio ZIP file based on your operating system from here and then extract the ZIP file.
The path to this folder will be referred to as <EI_TOOLING> throughout this tutorial.

Getting an error message? See the troubleshooting tips given under Installing WSO2 Integration Studio.
If you did not try the Transforming Message Content tutorial yet, open WSO2 Integration Studio, click File, and then click Import. Next, select Existing WSO2 Projects into workspace under the WSO2 category, click Next and upload the pre-packaged project. This contains the configurations of the Transforming Message Content tutorial so that you do not have to repeat those steps.
Download the MSF4J service from here and copy the JAR file to <EI_HOME>/wso2/msf4j/deployment/microservices folder. The back-end service is now deployed in the MSF4J profile of WSO2 EI. For more information on MSF4J, see the WSO2 MSF4 GitHub Documentation.

Let's get started!

Connecting to the back-end services

Let's create HTTP endpoints to the back-end services that you need to connect, in order to check the channelling fee and to settle the payment.

Right click SampleServices in the Project Explorer and navigate to New -> Endpoint. Ensure Create a New Endpoint is selected and click Next.

Fill in the information as in the following table:

Field	Value
Endpoint Name	ChannelingFeeEP
Endpoint Type	HTTP Endpoint
URI Template	`http://localhost:9090/{uri.var.hospital}/categories/appointments/{uri.var.appointment_id}/fee`
Method	GET
Static Endpoint	(Select this option because we are going to use this endpoint in this ESB Config project only and will not re-use it in other projects.)
Save Endpoint in	SampleServices

Click Finish.

Create another endpoint for Settle Payment and fill in the information as in the following table:

Field	Value
Endpoint Name	SettlePaymentEP
Endpoint Type	HTTP Endpoint
URI Template	`http://localhost:9090/healthcare/payments`
Method	POST
Static Endpoint	(Select this option because we are going to use this endpoint in this ESB Config project only and will not re-use it in other projects.)
Save Endpoint in	SampleServices

Click Finish.

You have now created the additional endpoints that are required for this tutorial.

Creating the deployable artifacts

In WSO2 Integration Studio, add a Property mediator just after the Get Hospital Property mediator in the in-sequence of the API resource to retrieve and store the card number that is sent in the request payload.

With the Property mediator selected, access the Properties tab and fill in the information as in the following table:

Field Value
Property Name Select New Property
New Property Name card_number
Property Action
Select set
Value Type Select Expression
Value Expression json-eval($.cardNo)
Description Get Card Number

For detailed instructions on adding a Property mediator, see Mediating requests to the back-end service.

Go to the first case box of the Switch mediator. Add a Property mediator just after the Log mediator to store the value for uri.var.hospital variable that will be used when sending requests to ChannelingFeeEP.

With the Property mediator selected, access the Properties tab and fill in the information as in the following table:

Field	Value
Property Name	Select New Property
New Property Name	uri`.var.hospital`
Property Action	Select set
Value Type	Select LITERAL
Property Data Type	Select STRING
Value	`grandoaks`
Description	Set Hospital Variable

Similarly, add property mediators in the other two case boxes in the Switch mediator. Change only the Value field as follows:
- Case 2: clemency
- Case 3: pinevalley
Delete the Send mediator by right clicking on the mediator and selecting Delete from Model. Replace this with a Call mediator from the Mediators palette and add GrandOakEP from the Defined Endpoints palette to the empty box adjoining the Call mediator.

Replace the Send mediators in the following two case boxes as well and add ClemencyEP and PineValleyEP to the respective boxes adjoining the Call mediators.

Replacing with a Call mediator allows us to define other service invocations following this mediator.
Let's use Property mediators to retrieve and store the values that you get from the response you receive from GrandOakEP, ClemencyEP or PineValleyEP.

Next to the Switch mediator, add a Property mediator to retrieve and store the value sent as appointmentNumber.

With the Property mediator selected, access the Properties tab and fill in the information as in the following table:

Field	Value
Property Name	Select New Property
New Property Name	`uri.var.appointment_id` (This value is used when invoking ChannelingFeeEP)
Property Action	Select set
Value Type	Select EXPRESSION
Value Expression	`json-eval($.appointmentNumber)`
Description	Get Appointment Number

You derive the Value Expression in the above table from the following response that is received from GrandOakEP, ClemencyEP or PineValleyEP:

{"appointmentNumber":1,   "doctor":
        {"name":"thomas collins",
         "hospital":"grand oak community hospital",
         "category":"surgery","availability":"9.00 a.m - 11.00 a.m",
         "fee":7000.0},
   "patient":
       {"name":"John Doe",
        "dob":"1990-03-19",
        "ssn":"234-23-525",
        "address":"California",
        "phone":"8770586755",
        "email":"johndoe@gmail.com"},
   "fee":7000.0,
   "confirmed":false}

Similarly, add two more Property mediators as follows. They retrieve and store the doctor details and patient details respectively, from the response that is received from GrandOakEP, ClemencyEP or PineValleyEP.

Field	Value
Property Name	Select New Property
New Property Name	`doctor_details`
Property Action	Select set
Value Type	Select EXPRESSION
Value Expression	`json-eval($.doctor)`
Description	Get Doctor Details

Property Name	Select New Property
New Property Name	`patient_details`
Property Action	Select set
Value Type	Select EXPRESSION
Value Expression	`json-eval($.patient)`
Description	Get Patient Details

Add a Call mediator and add ChannelingFeeEP from Defined Endpoints palette to the empty box adjoining the Call mediator.

Add a Property mediator adjoining the Call mediator box to retrieve and store the value sent as actualFee. Access the Property tab of the mediator and fill in the information as in the following table:

Field	Value
Property Name	Select New Property
New Property Name	`actual_fee` (This value is used when invoking SettlePaymentEP )
Property Action	Select set
Value Type	Select EXPRESSION
Value Expression	`json-eval($.actualFee)`
Description	Get Actual Fee

You derive the Value Expression in the above table from the following response that is received from ChannelingFeeEP:

{"patientName":" John Doe ", 
 "doctorName":"thomas collins", 
 "actualFee":"7000.0"}

Let's use the PayloadFactory mediator to construct the following message payload for the request sent to SettlePaymentEP.

{"appointmentNumber":2,
	"doctor":{
		"name":"thomas collins",
		"hospital":"grand oak community hospital",
		"category":"surgery",
		"availability":"9.00 a.m - 11.00 a.m",
		"Fee":7000.0
	},
	"patient":{
		"name":"John Doe",
		"Dob":"1990-03-19",
		"ssn":"234-23-525",
		"address":"California",
		"phone":"8770586755",
		"email":"johndoe@gmail.com"
	},
	"fee":7000.0,
	"Confirmed":false,
    "card_number":"1234567890"
}

Add a PayloadFactory mediator next to the Property mediator, from the mediators palette to construct the above message payload.

With the Payloadfactory mediator selected, access the properties tab of the mediator and fill in the information as in the following table:

Field	Value	Description
Payload Format	Select Inline	-
Media Type	Select json	-
Payload	{ "appointmentNumber":$1, "doctor":$2, "patient":$3, "fee":$4, "confirmed":"false", "card_number":"$5" }	The message payload to send with the request to SettlePaymentEP. In this payload, `$1`, `$2`, `$3`, `$4`, and `$5` indicate variables.

We will look at adding the value for the field Args in the following steps.

To avoid getting an error message, first select the Media Type before providing the Payload.

To add the Args field for the PayloadFactory mediator, click the Add (+) icon in the Args field and enter the following information as in the table below. It provides the argument that defines the actual value of the first variable used in the format definition in the previous step.

Field	Value	Description
Type	Select Expression	-
Value	`$ctx:uri.var.appointment_id`	The value for the first variable ($1) in the message payload format.
Evaluator	Select xml	Indicates that the expression provided is in XML.

The $ctx method is similar to using the get-property method. This method checks in the message context. For more details on using this method, refer the documentation.

Similarly, click Add and add more arguments to define the other variables that are used in the message payload format definition. Use the following as the Value for each of them:
$ctx:doctor_details
$ctx:patient_details
$ctx:actual_fee
$ctx:card_number
Add a Call mediator and add SettlePaymentEP from Defined Endpoints palette to the empty box adjoining the Call mediator.
Add a Respond mediator to send the response to the client.
You should now have a completed configuration that looks like this:
Save the updated REST API configuration.

Packaging the artifacts

Since you created new endpoints, these will need to be packaged into our existing C-App.

Package the C-App names SampleServicesCompositeApplication project with the artifacts created.

Ensure the following artifact check boxes are selected in the Composite Application Project POM Editor.

SampleServices
- HealthcareAPI
- ClemencyEP
- GrandOakEP
- PineValleyEP
- ChannelingFeeEP
- SettlePaymentEP
SampleServicesRegistry

Starting the ESB profile and deploying the artifacts

Assuming you have already added a server for the ESB profile in Eclipse, on the Servers tab, expand the WSO2 Carbon server, right-click SampleServicesCompositeApplication, and choose Redeploy. The Console window of the ESB profile will indicate that the CApp has been deployed successfully.

If you do not have a server added in Eclipse, refer this tutorial.
You can also deploy the artifacts to the ESB server using a Composite Application Archive (CAR) file.

Starting the MSF4J profile

To be able to send requests to the back-end service (which is an MSF4J service deployed in the MSF4J profile), you need to first start the MSF4J runtime:

Open a terminal and navigate to the <EI_HOME>/wso2/msf4j/bin directory.
Start the runtime by executing the MSF4J startup script as shown below.

The Healthcare service is now active and you can start sending requests to the service.

Sending requests to the ESB

Create a JSON file named request.json with the following request payload.

{
"name": "John Doe",
"dob": "1940-03-19",
"ssn": "234-23-525",
"address": "California",
"phone": "8770586755",
"email": "johndoe@gmail.com",
"doctor": "thomas collins",
"hospital": "grand oak community hospital",
"cardNo": "7844481124110331",
"appointment_date": "2025-04-02"
}

Open a command line terminal and execute the following command from the location where the request.json file was saved:

curl -v -X POST --data @request.json  http://localhost:8280/healthcare/categories/surgery/reserve  --header "Content-Type:application/json"

This is derived from the URI-Template defined when creating the API resource.

http://<host>:<port>/categories/{category}/reserve

You will see the response as follows:

{  
   "appointmentNo":1,
   "doctorName":"thomas collins",
   "patient":"John Doe",
   "actualFee":7000.0,
   "discount":20,
   "discounted":5600.0,
   "paymentID":"480fead2-e592-4791-941a-690ad1363802",
   "status":"Settled"
}

You have now explored how the ESB profile of WSO2 EI can do service chaining using the Call mediator and transform message payloads from one format to another using the PayloadFactory mediator.

Browser not supported