I am trying to setup a simple service that publishes a document and a reply is returned (SYNC) from the subscribing side. Two servers involved - one to publish and one to receive/publish reply. Problem is the reply document is stuck in the client queue on the broker (confirmed via MWS). I have to source document and the reply document defined on each server in the exact same location and both are set to publishable The input for the publishAndWait has the fully qualified path set for the service AND the main service inputs. The publishAndWait side is waiting for 60000 ms and is set to Sync.
I’m scratching my head on this one - can anyone offer any suggestions.
SRC Server issues a publish:publishAndWait
TGT Server issues a publish:reply (a trigger calls this service so it can process the data and issue the publish:reply)
I checked MWS and saw the following message:
Error: Invalid or nonexistent queue browser for client “155.110.140.36_6666_RequestReplyClient” on Broker “MsgBroker@spartan28.spartanstore.com:6849”.
So, I cleared the queue, deleted the clients and restarted IS (the publish side IS).
Now, after a reboot, I’m seeing the following message in the publish side IS server log:
[ISS.0098.0038C] _DefaultClient handling invalid Document. Exception: com.wm.app.b2b.server.dispatcher.exceptions.InvalidDocumentException: [ISS.0098.9006] No matching Document Type exists for wm::is::<CUSTOM_REPLY_DOC>
Odd because I’ve sync’d the document (push to broker) several times and both the main document and reply document on both sides. I have to be missing something obvious here…
It seems progress has been made and the publisher is at least now trying to process the reply.
Double-check all the places where a document type is specified, looking for possible trailing spaces, etc. Another fun thing about the integration between Developer, IS and the Broker is that if things get out of sync Developer will append a number on the end of the document type name. So you get Foo_1 instead of the desired/expected Foo. You may need to make the doc unpublishable and then publishable again to get the desired broker doc type name.
Thanks for the response. I’m still struggling with the solution and I’ve done a few things since. First, and foremost, I’ve rebooted the broker/mws server. Below are the next steps…
Deleted the package containing the publishable documents as well as all links to them (then an OS reboot) and restored from QA environment (we keep all publishable docs in one package as a rule). This was followed by an IS restart
Recreated the “reply” publishable document
Re-mapped the service.
Deleted the references to old documents in the IntegrationServer client group within MWS.
Tried to issue a publish and wait (both sync and async) and I’m getting the following error:
“[ISS.0098.9065] Error reply pub.publish.notification:error received. adapterType:Integration Server, errorCategory:Application,errorText:com.wm.app.b2b.server.ServiceException: [ISS.0098.9014] BrokerException: No Permission (109-1374): Cannot publish the document. Permission is denied. Check the ‘can publish’ permissions in the client’s client group.
,eventId:-615590172112390096”
Odd thing is that I’ve looked at the publishable document properties and the broker doc type doesn’t have the infamous ‘_1’ or ‘_2’ etc. on either server (the publishing server or the subscribing server). I did have that before and after the cleanup, I fixed that. I’ve also synced all the documents on both servers.
In reference to the above message, I’ve looked in the IntegrationServer client group and the documents appear in the can publish and can subscribe tabs. This is getting kinda silly now. It can’t be that hard to accomplish this…
Just tried that and it didn’t help the issue. It did, however link the broker doc type on the 2nd server to the infamous ‘_1’ for the broker doc type. Not sure if that is going to present an issue.
Did that - still showing the _1 at the end. I set to NON publishable, saved, deleted, copied from other server, set to publishable and same broker doc type reference. Looks like I’ll have to delete it and then re-install the package from a zip file.