| Author |
Message
|
| Yoel |
 Posted: Mon Jun 06, 2016 3:00 am Post subject: IIB v10 Integration Services and Aggregation |
 |
|
Novice
Joined: 03 Apr 2012
Posts: 17
|
I am about to migrate to IIB v10 and planning to use Integration Service projects for SOAP based services.
My wonder is what to do with my aggregation services.
I want to use the built in aggregation nodes, but that forces me to break the main flow and to touche the generated flow.
any ideas??
thanks |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Mon Jun 06, 2016 4:22 am Post subject: Re: IIB v10 Integration Services and Aggregation |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Yoel wrote: |
I am about to migrate to IIB v10 and planning to use Integration Service projects for SOAP based services.
My wonder is what to do with my aggregation services.
I want to use the built in aggregation nodes, but that forces me to break the main flow and to touche the generated flow.
any ideas??
thanks |
Explain why you think that...
I would assume that you would keep a queue manager assigned to the broker... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Yoel |
| Posted: Mon Jun 06, 2016 9:24 am Post subject: Re: IIB v10 Integration Services and Aggregation |
|
|
Novice
Joined: 03 Apr 2012
Posts: 17
|
| fjb_saper wrote: |
Explain why you think that...
I would assume that you would keep a queue manager assigned to the broker... |
By "Interation Service" I refer to the new type of application project that is based on a WSDL.
In the toolkit I get a special designer that is based on the wsdl operations.
when clicking an operation a subflow is opened.
The flow itself is generated for me, and in order to break it into two flows for fanOut and fanIn flows I am touching something I am afraid is not a good idea to touch. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Jun 06, 2016 10:25 am Post subject: Re: IIB v10 Integration Services and Aggregation |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Yoel wrote: |
| fjb_saper wrote: |
Explain why you think that...
I would assume that you would keep a queue manager assigned to the broker... |
By "Interation Service" I refer to the new type of application project that is based on a WSDL.
In the toolkit I get a special designer that is based on the wsdl operations.
when clicking an operation a subflow is opened.
The flow itself is generated for me, and in order to break it into two flows for fanOut and fanIn flows I am touching something I am afraid is not a good idea to touch. |
The only problem you will have is to pass the reply token from the fanOut to the FanIn flow, if you have those in different flows.
There is nothing to prevent you from having both fanout and fanin in the same flow...
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Yoel |
| Posted: Mon Jun 06, 2016 11:27 am Post subject: Re: IIB v10 Integration Services and Aggregation |
|
|
Novice
Joined: 03 Apr 2012
Posts: 17
|
| fjb_saper wrote: |
The only problem you will have is to pass the reply token from the fanOut to the FanIn flow, if you have those in different flows.
There is nothing to prevent you from having both fanout and fanin in the same flow...
Have fun |
Sounds good. 
1. Any Idea why the normal samples of aggregation are always separated into at least two flows (fanOut and fanIn)?
This separation forces me to keep state of the repyIdentifier between the flows, and complicates the correlation in the logging.
2. Do you have an idea about the replyIdentifier when using the same flow?
Would It be handled automatically as a normal SoapReply situation, or the fact I added another inputNode will add an extra thread and SoapReply node will fail to guess the right replyIdentifier? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Jun 06, 2016 7:53 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Typically I would use 2 flows as they can then scale differently. A dummy service will be called in the aggregation. That service receives a message with the reply token on the fan out and returns it to the aggregation on the fan in...
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jun 07, 2016 4:14 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Also, yes, it's fine to change the generated message flows.
You should just rename them/move them/whatever so they don't get overwritten if you regenerate...
As FJ says, you can send addtiional messages to the Aggregation nodes to pass data between the two flows.
You could also store data in the global cache. And there's some stuff about the SOAP Reply being available in things that are part of the same msgflow file - or maybe the same library/application...
I forget. Perhaps mgk will stop by and remind me of how wrong I am.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
|
|
