|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
How are some of you using MQSI at work ? |
« View previous topic :: View next topic » |
Author |
Message
|
AlexeiSkate |
Posted: Wed May 29, 2002 8:40 am Post subject: How are some of you using MQSI at work ? |
|
|
Centurion
Joined: 10 Apr 2002 Posts: 123
|
Hi,
I was wondering if anyone has use MQSI to do complicated intergration and how do you find the process to be. We're using MQSI/MQS for the first time to implement some interfaces that would have normally been done as SQR programs. One of the interfaces require the reading in of parameter files, pulling reference records from the database to add to the message, updating rejecting records to the database, pulling rejected records from the db to reprocess them, generating reports, grouping related input records together to generate a message....
I went to a week of MQS/MQSI training provided by IBM and we did very basic exercises like creating queue, q mngrs, creating simple msg flows... So to go from that and then try to implement what some of the interface designs are asking is kind of overwhelming. Are some of the requirements that I've mentioned possible using MQSI, or would some of the processes, like the grouping of related input record, require an external program to generate the message and MQSI should only worry about doing the mapping.
I guess I just want an idea of how complicated some of the integrations applications can be using MQSI.
Thanks,
Alex |
|
Back to top |
|
 |
kirani |
Posted: Wed May 29, 2002 9:59 am Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001 Posts: 3779 Location: Torrance, CA, USA
|
Alex,
This is a very broad question! Indeed, WMQI is capable of doing complicated processing as stated in your requirement. As such you cannot interact with files directly within WMQI, so you will have to write some external program to load data into db or queue or write a plug-in node, which does this.
What is the throughput you are looking at for your interfaces? If you have a very tight window and if you are looking at higher number of messages/sec, you should also consider writing external programs and do transformation/routing/.... in WMQI. _________________ 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 |
|
 |
JLRowe |
Posted: Wed May 29, 2002 12:48 pm Post subject: |
|
|
 Yatiri
Joined: 25 May 2002 Posts: 664 Location: South East London
|
I'd love to work on a project with WMQI, where MQ workflow is used to handle the state management. The logic on each end system would then be minimal and all the business logic is contained entirely within WMQI and WMQWF. |
|
Back to top |
|
 |
kwelch |
Posted: Thu May 30, 2002 5:13 am Post subject: |
|
|
 Master
Joined: 16 May 2001 Posts: 255
|
Johnathan,
So you are saying that you would do all your business logic, editing, formatting, database updates, etc. in WMQI?
We have been mainly using WMQI for data transformation and routing and are trying to stay away from doing edits for fear of performance issues.
Also, I am curious how workflow fits in? I don't know much about that product.
Regards,
Karen |
|
Back to top |
|
 |
JLRowe |
Posted: Thu May 30, 2002 6:33 am Post subject: |
|
|
 Yatiri
Joined: 25 May 2002 Posts: 664 Location: South East London
|
My idea is that keeping all the logic in one place (WMQI) is prefrable to having some of it in WMQI and the rest in the various end systems you are connecting (coded in Cobol, java, c etc etc). This would make a complex integration project easier to manage and more responsive to change requests.
To be honest, in my experience I have never run into performance problems with WMQI. Running multiple instances of a flow, or using MQ clustering with multiple brokers will solve most performance problems.
Workflow allows the management of long running transactions, which could potentially consist of many seperate message flows over a long period of time. An example would be a stock trading system, where a single 'stock buy' transaction could involve flows going to and from various partner systems. WMQI works on the individual flow level, workflow works at the higher 'stock buy' transaction level. |
|
Back to top |
|
 |
kwelch |
Posted: Thu May 30, 2002 7:10 am Post subject: |
|
|
 Master
Joined: 16 May 2001 Posts: 255
|
Thanks for the explanation. How many messageflows, compute nodes, database connections, etc. are you talking? Can you give me a ballpark? Also, roughly how much ESQL in those compute nodes? We did a proof last summer and it performed like a champ. Being new to the product and rushed, I did it all in one compute node and ended up with 10,000 lines of ESQL code(not too easy to maintain!). Currently, we are reworking that whole project with more data, more ESQL and I am breaking it up into more maintainable pieces and ended up with around 20 compute nodes in my messageflow and am wondering how performance will be impacted.
Karen |
|
Back to top |
|
 |
kirani |
Posted: Thu May 30, 2002 7:46 am Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001 Posts: 3779 Location: Torrance, CA, USA
|
Karen,
It is recommended to use minimal compute nodes within a message flow. Its is a good idea to put long ESQL code in a single compute node, but from maintenance perspective it becomes difficult. Sometimes Control Center takes forever to bring up the ESQL code. In that case start splitting your ESQL into multiple compute nodes.
Jonathan,
It purely depends on what "complex" means and what is your environment. Sometimes one may come across a situation where they have to process millions of records in a very narrow batch window (1 hr or so). Before these records are transformed they have to undergo some preprocessing, like checking for duplicate records (within file and against last 15 days ), sorting, merging, .....
These things cannot be done very efficiently in WMQI. You will have to do multistage processing to do this. I would prefer to write COBOL/C++/C/Java program to do pre processing and then do transformation in WMQI.
Most of the times business case drives your logic. If there is a dependency between records, they cannot be processed in parallel, so multiple instances is not an option in this case.
There is no right or wrong answer to this question. This is what i thin I would do. I would evaluate the business requirement and see how best it can be fit in WMQI. If need arises I would consider other options to do "complex business processing" and use WMQI for Transformation/Routing/... _________________ 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 |
|
 |
meekings |
Posted: Fri May 31, 2002 7:08 am Post subject: |
|
|
 Voyager
Joined: 28 Jun 2001 Posts: 86 Location: UK, South West
|
Apropos of performance: there is a SupportPac for estimating WMQI throughput (IP03 - Capacity Planning Tool). It's not hugely sophisticated, and may not relate directly to the platform you're using, but it can give you ballpark relative throughput numbers for, say, 1 complex Compute node vs 20 simple ones, persistent vs non-persistent etc. |
|
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
|
|
|
|