Hi,
I am using PublishAndWait service.
The package that uses PublishAndWait and package that subscribes to the Published document and reply are residing in the same Integration Server.
The challenge is, whenver the service calls PublishAndWait, the subscribing service which replies is not invoked unless it’s timedout. ONce it’s timedout, then only the subscribing service is invoked. But if we put the same package in other Integration Server and point to the same broker, it’s working fine. Can anyone suggest the workaround for the same.
With Regards,
Navanee
Hi Navanee,
AFAIK,If the waitTime elapses before the service receives a reply, the Integration Server ends the request, and the service returns a null document that indicates that the request timed out. The Integration Server then executes the next step in the flow service. If a reply document arrives after the flow service resumes execution, the Integration Server rejects the document and creates a journal log message stating that the document was rejected because there was no thread waiting for the document.
How come “whenver the service calls PublishAndWait, the subscribing service which replies is not invoked unless it’s timedout. Once it’s timedout, then only the subscribing service is invoked.”
once the subscribing service is invoked (after timeout), are you getting null document as reply ? or excepted reply i.e. not null document ??
Regards,
Puneet Saxena
Hi Puneet,
Thanks for your response…
The Subscribing service is not invoked unless it’s timeout. After timeout then subscribing service starts the process, it sends the proper reply document what is expected. But when it sends the reply, there will be no service waiting for the response. I feel there is something that we need to do the Broker setting or Integration Server Setting… Not sure about it…
With Regards,
Navanee
Hi,
I just got a thinking.
Why do u want to use publish and subscribe if both the services are in the same IS. You can directly call the subscribing service inside the publishing service and do the mapping accordingly. If the services are in different machines, then anyway u will need publishandwait.
Nvarma.
Hi Varma,
It’s being the architecture design that’s being followed as the servers are segregated logically.
With Regards,
Navanee
Hello Navanee,
AFAIK ,the architechtural design you are using, is used when the integrations are residing in the Broker, ie older versions of wM. I never used that in the IS. But may be I am missing something. Also when the services are in the same IS the document should be published locally. You will need to publish the document to Broker only when you want the document across different IS’s .And the delayUntilServiceSuccess should be set to false in the Publishwait step.Let me know if this works.
Hi NVarma,
While defining the architecture of an integration, one should take into account NOT ONLY what is the current requirement but what will be required in near future.
Looks like in this scenario, though currently there is only 1 IS but in near future there is possiblity of adding more IS, all connected to the same broker.
In that case, the current code shouldn’t publish the document locally.
Regards,
Bhawesh,
Yeah if new ISs are added then it is necessary to publish the document to broker. But I dont understand the necessity to use publish and wait when the services are in the same IS. Instead we can call it directly…
Any idea?
NVArma
Hi NVarma,
If the requirement is just to publish a document to broker and the document gets cosumed by the subscribing service, then instead of PublishAndWait, the Publish service should be used.
If another IS is likely to be added in near future and in the current code if you invoke the subscribing service directly(without configuring the broker), then it will be big code change required in near future(including configuring the broker).
I will reiterate here that while developing a solution one should also take care of where integration is moving in near future.
Bhawesh,
Let me summerise here :
Case 1 : If the source integration(package) is in one IS and target integration(package) in another IS, then its true that they need to publish to broker and should use Publishandwait.
Case 2 : And if both source and target integrations are in the same IS, then, there might be a possiblity that a new IS might be added in future and the target might me moved to it.
Case 3 : If the publishing service and subscribing service are in the same package, then there is no need to use publishand wait. Also no need to publish the document to broker.
It depends on how the current implementation Navanee is using.
Am I missing anything?
Nvarma.
Hi NVarma,
Hope the following scenarios make it clear:
Case1: 1 IS creates a document and same IS consumes that document and there is no possibility that this document will be used by some other IS or other client now or in near future.
Solution: Don’t define any publishable document and don’t define any broker
Case2: 1 IS creates a document and currently same IS consumes that document but there is a possibility that this document will be consumed by some other IS or other client in near future.
Solution: Define the document as publishable, publish the document to broker using Publish service, subscribe to the document by the same IS. When the next IS or other client is added to the broker, it will subscribe to the doc and consume it in its own way.
Case3: 1 IS creates a document and publishes the document1 to the broker and needs to wait for a return document2 from the subscribing client (which could be the same IS for now) and there is possibility that this document will be used by some other IS or other client in near future.
Solution: Define the document as publishable, publish the document to broker using PublishAndWait service, subscribe to the document by the same IS. When the next IS or other client is added to the broker, it will subscribe to the doc and consume it in its own way.
Regards,
Bhawesh
Bhawesh,
Good discussion we had in this thread. Hope this will help Navanee in solving the issue.
Regards,
Nvarma.