| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Help with Message Flow Design |
« View previous topic :: View next topic » |
| Author |
Message
|
| jlalbor |
 Posted: Thu Mar 10, 2005 6:03 pm Post subject: Help with Message Flow Design |
 |
|
Apprentice
Joined: 18 Feb 2003
Posts: 38
|
We ve the following need:
We have some applications that will request some account data sending a XML message to a queue and reading the reply in another queue, the reply is also a XML message.
The Broker will take the request that the application sends and with the information contained in this request, the broker has to create several CWF messages using data from the incomming message and several databases, and send them to a queue in a Z/OS.
Then, the CICS Bridge running on the mianframe takes the requests, executes some CICS transactions and sends the replies to different queues according to the replyQ that the incomming request had. Then the Broker has to combine the data contained in the replies and create a XML
message as a reply for the aplication that started the flow.
Lets say that the transactions are TSCCRE01 and TSCCRE02.
The problem is that we need to execute first the TSCCRE01 transaction and recieve the reply, then we need to review the data in the reply and if necesary execute transaction TSCCRE02 and wait for the reply.
After recieving the reply of the second transacction we need to review the data of this reply, and in some conditions execute the TSCCRE02 transaction again with new data. The execution of the second transaction is a loop and the condition for executing it again or not depends on the reply info.
After the execution of this transacctions we need to combine all the replies recieved and return a response with all the data combine in a unique response.
I think that the Aggregate Nodes can not deal with this kind of situation where not all request are send
in the same message flow and, where the number of requests are unkown and depend on the information in the replies.
Has anyone any ideas on how to resolve this?
We are thinking to development a custom Java node that sends a message to a queue and reads the reply in another queue and puts the response in the local environment so we can retain all the replies information in the message flow, but we will like to know if there is a better solution for this.
Thanks. |
|
| Back to top |
|
 |
| Nizam |
| Posted: Fri Mar 11, 2005 8:22 am Post subject: |
|
|
Disciple
Joined: 10 Feb 2004
Posts: 160
|
1. Fan out
Take the request convert the xml to cwf and send it to mainframe. Since you are using CICS Bridge you need to perform additional steps like set the first 8 characters as the name of the program, set msgid to new(not sure). You fan out 3 messages. request to mainframe, a copy of your original msg and control message.
2. Fan In
Take the response from mainframe and aggregate with your original msg and control message and send it to the response queue.
3. Exception handling will be very complex. Since you can have several kinds of failures like time outs in aggregate nodes, business errors, other broker exceptions, handling error messages from mainframe.
4. You need to consider the size of messages that you will be processing, throughput required etc., If you need to process large messages and need a high throughput......you need to look at the performance support packs/capacity planning and then design your flows.
It will be fun doing this project.
Nyzam.
_________________
Nyzam
IBM Cert. Solution Designer - WBIMB V5
IBM Cert. Administrator - WBIMB V5
IBM Cert. Administrator - WebSphere MQ V5.3 |
|
| Back to top |
|
|
| JT |
| Posted: Fri Mar 11, 2005 10:06 am Post subject: |
|
|
Padawan
Joined: 27 Mar 2003
Posts: 1564
Location: Hartford, CT.
|
| Quote: |
Has anyone any ideas on how to resolve this?
We are thinking to development a custom Java node that sends a message to a queue and reads the reply in
another queue and puts the response in the local environment so we can retain all the replies information
in the message flow, but we will like to know if there is a better solution for this |
We have some applications that have been successfully using this very solution. When the Aggregate nodes aren't a good fit, the applications use a custom plug-in that mimics the functionality of the IA09 MQGet plug-in, which is currently on the 'withdrawn' list. The flow is something like this:
- MQInput node: consumes the XML request message
- Compute node: builds the TSCCRE01 request
- MQOuput node: sends the TSCCRE01 request
- MQGet node: waits/consumes the TSCCRE01 reply, and stores the reply in the Environment tree
- Compute node: interrogates the TSCCRE01 reply, and if necessary builds the TSCCRE02 request, otherwise builds the XML reply
- MQOuput node: sends either the TSCCRE02 request or the XML reply
- Filter node: determines if the message sent was the TSCCRE02 request
- MQGet node: waits/consumes the TSCCRE02 reply, and stores the reply in the Environment tree
- Compute node: interrogates the TSCCRE02 reply, and if necessary builds another TSCCRE02 request, otherwise builds the XML reply
- MQOuput node: sends either another TSCCRE02 request or the XML reply
- Connect the last MQOuput node to the Filter node and you're in a loop until further TSCCRE02 requests are no longer required. When you're ready to build the XML reply message, the aggregated CICS data is available via the Environment tree.
You can also employ variations, splitting the message flow into seperate flows and using a data/memory store to aggregate the replies. But the method above allows us to report to the front-end application the very nature of a problem/time-out of the back-end application |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
