| Author |
Message
|
| jdouch |
 Posted: Mon Jun 24, 2002 11:27 am Post subject: WMQI Workflow/Orchestration |
 |
|
Apprentice
Joined: 31 May 2002
Posts: 32
Location: London, UK
|
Hi,
I am currently working for a major UK retailer on a WMQI project. Release 1 of the project simply sent data from interfaces on a mainframe to a sourcing and tracking application named QRS. All the interfaces were controlled using batch schedules and OPC.
In release 2 we now have WMQI sitting in the middle which is event based which may cause us potential problems. There would appear that there are some dependancies between interfaces where Interface 1 must be finished and processed correctly before interface 2 starts. Using WMQI we have no knowledge of when that batch is finished.
Therefore, currently we have no way ensuring this happens, the number of messages being sent in the batch is unknown too. Curently we are just looking to schedule these as far apart in the batch window as possible.
So does anyone have any experiences / best practices as to how to get around this - we have workflow engine either such as IBM Workflow. We also start integration testing next week so any thoughts would be grateful
thanks
Julian
_________________
Julian Douch
E-business Solutions Consultant
WMQ/WMQI Specialist |
|
| Back to top |
|
 |
| TorpedoSTu |
| Posted: Mon Jun 24, 2002 11:54 pm Post subject: |
|
|
Acolyte
Joined: 14 Nov 2001
Posts: 73
|
forgive the simplistic view but ......
can't you store the incoming messages in a warehouse node. When interface 1 finishes, send a message to SI that start interface 2
Regs
Stu |
|
| Back to top |
|
|
| jdouch |
| Posted: Tue Jun 25, 2002 12:05 am Post subject: |
|
|
Apprentice
Joined: 31 May 2002
Posts: 32
Location: London, UK
|
Stu,
thanks for your response. the start of interface two can not start until the receiving application has finished processing the messages sent from WMQI. Any messages sent in batch to WMQI get processed as individual messages and therefore lose the 'batch'. There is no control message to signify the end of the batch or how many messages were in the batch.
Therefore correlation of that batch on the outbound side of WMQI is proving quite difficult!
rgds
Julian
_________________
Julian Douch
E-business Solutions Consultant
WMQ/WMQI Specialist |
|
| Back to top |
|
|
| TorpedoSTu |
| Posted: Tue Jun 25, 2002 1:05 am Post subject: |
|
|
Acolyte
Joined: 14 Nov 2001
Posts: 73
|
How do you know that Interface 1 has stopped ?. If this is not possible to know, hten your problem is insurmountable !
If you do know, then sending an 'end of file' message is the answer
Regs
Stu |
|
| Back to top |
|
|
| kirani |
| Posted: Tue Jun 25, 2002 7:27 am Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
Julian,
few questions ..
1. What are you using WMQI for? Is it used for transformation of data from interfaces 1-n before it is sent to QRS?
2. Does QRS processes data in batch mode or real-time mode?
3. Do you get files from Interfaces?
4. Is it a requirement that you should control message flows using some scheduler?
5. Currently how do you control dependency between the interfaces?
We are also working on interfaces in batch mode. May be I can help after I know what exactly you are trying to do.
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| jdouch |
| Posted: Tue Jun 25, 2002 7:47 am Post subject: |
|
|
Apprentice
Joined: 31 May 2002
Posts: 32
Location: London, UK
|
Hi Kiran,
Thanks for response - fortunately today we've met and removed the batch way of thinking, and gone for a complete asynchronous system. But in answer to your question anyway...
1. We take one form of XML from mainframe from multiple interfaces, perform some business logic and transformations to another form of XML which is then passed to the QRS system.
2. QRS is similar to WMQI in that it continually polls the input q for messages and therefore processes messages in real time.
3. As i say we pick off XML messages which have been sent from the mainframe interfaces.
4. I think the main point that came out of our dicussions today was that time scheduling is not necessary a good way to go when you have interface dependancies, due to all the other unknowns such as communication problems etc. Scheduling the message flows was an option, but unfortunately it doesn't guarentee that all the messages were processed in the QRS target system successfully
5. In release 1 of the project they were not using WMQI, straight MQ all running in batchs and controlled by OPC
The feeling was that trying to combine a batch system with a real time one is not a good one !
thanks
Julian
_________________
Julian Douch
E-business Solutions Consultant
WMQ/WMQI Specialist |
|
| Back to top |
|
|
| dhaksr |
| Posted: Wed Jun 26, 2002 11:19 am Post subject: |
|
|
Apprentice
Joined: 20 Feb 2002
Posts: 37
|
Julian,
In our project, we need to have batch interfaces.
What we are thinking to do is build in the Scheduler dependency...
1. We have Source Adapter (SA) which puts the file records into Queue
as messages. In addition it puts a Header and Trailer Messages.
2. WMQI transforms the messages and puts into Target Queue.
3. Target Queue is defined for triggering, with a CATCH. It will do
triggering based on Priority Level. (i.e. A program will be triggered
only if a particular priority message comes). Our message flows
are desinged in such a way that Data Messages will be put as normal
priority. Trailer Message is defined with High Priority.
4. Trailer Message goes to the top of the Queue and Triggers the Target
Program. In our Case, it will inform the scheduler to start a Job.
I hope this clarifies and you can still consider having batch interfaces.
Good Luck
Dhaks |
|
| Back to top |
|
|
|
|
