To manage dynamic responses within the ESB when in its services throw either a valid response or a faulted one, we implemented the following scenario that may help you with similar cases.
First you have to take into account serveral important points:
An itinerary can define dynamically its response paths. Within an itinerary you can define if a service will respond or not. This isn’t quite a visible property, but it can be used to define if the itinerary service will respond to the client or to the following service.
This will be the scenario used in our use case.
An orchestration can handle one-way or two-way processes, seen as a process that can be design from the itineraries. You don’t have to explicitly place the two-way ports to handle this type of processes. In some cases, handling orchestrations with two-way ports doesn’t allow a simple management of the process since the process is always going to demand for a response when the Decision shapes are used. This means that the process will be required to return a response in all branches of the Decide Shape (“If”,“Else”, etc). Sometimes this becomes too complex to deal with.
Orchestration that responds with a two-way port (not being used in our example):
Orchestration that responds with a one-way port (being used in our example):
Using Dynamic Responses in Chained Operations within Itineraries.
This a preview taken from the original ESB Toolkit Use Case, to us it will be the Dynamic Responses in Chained Operations within Itineraries use case.
As you can see, the services can respond to the next service or respond to the client that made the call.
Implementation Detail:
1. The incoming (On-Ramps) message is received within the ESB through the WCF Service Itinerary Services Response, this comes with the ESB Toolkit, 2.0 o 2.1.
2. The call is made through the ESB Toolkit Itinerary Tester Client, we added it to our solution to make the tests.
3. The defined itinerary is as follows:
The message is received and processed by the CustomOrchestration1 orchestration, then the result is sent to CustomOrchestration2 which processes and responds to the caller.
Lets take a look to the properties of each shape:
Receive Order
CustomOrchestration1 (Ochestration Extender)
CustomOrchestration1 (Ochestration Extender)
4. The detail of the Orchestrations is as follows:
CustomOchestration1
This orchestration receives a message of the type Initial Order and transforms it to a message type CustomOrchestration1. Here we see two types of possible behaviors. If the Quantity field is equal Zero ( 0 ), an exception is thrown and responded to the caller.
The exception is handled with the ESB Exceptions Framework and published directly to the MessageBox. This same port is used to respond with the exception and to send the message to the following step.
In the Construct Shape Construct Outoubound Message, the message is constructed for the following step.
It is important to note that we use the correlation itineraryRequestResponse when sending the fault. This applies for both, CustomOrchestration1 and CustomOrchestration2.
CustomOchestration2
The difference between this orchestration and CustomOrchestration1, is the validation of the field. This one makes it with Total, validates if the Total is equal to zero and throws an exception. If the exception is thrown it is sent as a response to the caller, otherwise the response will be of type CustomOrchestration1. Bellow an example with its results:
a. The caller sends OK data. Quantiy has a value and Total has a Value. Then it goes through CustomOchestration1, CustomOrchestration2 and responds to the caller:
Message
DebugView
Itinerary Test Client
b. Caller sends data with Quantity in zero, Total with a value different from zero, goes through CustomOchestration1, this orchestration generates an error and sends the response to the caller, it doesn’t go through CustomOrchestration2.
Message
DebugView
Itinerary Test Client
c. The Caller sends data with Quantity ok. The Total with zero value, the message is processed by CustomOrchestration1 and sent to CustomOrchestration2. This orchestration generates an error and sends it as a response to the caller.
Message
DebugView
Itinerary Test Client
With all these three examples we could prove how the ESB can manage adequate responses when the message is correctly processed and also to give a response when the message isn’t processed correctly. Also, we can check in the ESB Portal the message and check the used itinerary.
Here is the sample code (install in “C:\Projects” folder):
iTSynergy.ESB.ChainedOperations_BTS2010_ESB_2.1.zip
iTSynergy.ESB.ChainedOperations_BTS2009_ESB_2.0.zip
