what you refer to as “Broker base model” is what we officially call “webMethods Messaging”. It is the use of publishable document types, wM Messaging triggers and the pub.publish:* services. This is indeed supported by both Broker and UM.
The synchronization of document types works in the same way for both Broker and UM. The only exception is when you make a change to a doc type that is configured with Encoding = IData, then you don’t actually have to resync the doc type, because the Channel in UM already exists.
However, to get the closest behavior to Broker, we recommend using Encoding = Protocol Buffer, and that encoding DOES require you to resync the doc type after you make a change to it.
So as a general rule: always remember to sync the doc type when you make a change and you shouldn’t have problems.
Yes, i was referring to the webMethods Messaging model only. And thanks for correcting me here.
And i was unaware of this encoding type feature for publishable documents until now.
Glad to know the same.
I tried doing the same exercise again using the protocol buffer as encoding.
However, there is no change in test results for test case where the publishable document is out of sync after doing the modifications.
And also, i observed the below things, which was little confusing to me.
with publish service and IDATA as encoding, I’m able to see the data by snooping the channel even after i successfully received the data at target side
And also, with every pausing and continuing of the snooping, the last event is getting re-appeared again and again with same eventID.
But when i stop and start the snooping, all the re-appeared data is not visible.
However, which is not the case with deliver service with IDATA as encoding
And publish/deliver service with protocol buffer as encoding
which is leading me to predict that, the data is still present in queue itself in case of publish with IDATA encoding. However which is not the case.
If you change the encoding to Protobuf and resync, you will need to restart Enterprise Manager before snooping again, otherwise the individual fields will not be displayed.
Snoop itself is not a view on the queue. It is an additional subscriber on the channel, so when you start the snoop, it will display all messages published to that channel from that moment onwards (until you stop it), irrespective of any other subscribers. So seeing a message in the snoop panel doesn’t mean it is in the queue - the snoop panel is viewing messages from Enterprise Manager memory, after they have been subscribed.
I would like to have bit more inputs regarding this encoding type “Protocolbuf”.
We have a typical issue in our env where the triggers not subscribing post deployment. But when we manually edit the triggers “Disable/Save/Enable/Save”, the triggers starts to work. This issue is completely inconsistent and cannot be reproduced. We are in migration phase and faced this issue in every low env thats restricting us to move for PROD.
Unfortunately, the service “migrateDocTypesTriggersToUM” was not executed in our env, i.e, we still have IDATA as encoding type and filter conditions not changed and opted for server side. Also we are syncing the doctypes every time post the deployment.
And we are also facing issues running the service with the below error.
Could not run ‘migrateDocTypesTriggersToUM’
We doubt of the belwo things but not sure exactly which one is causing this issue.
Presence of lex opr. We presume, it will hit us in performance but not sure its reason for the subscribing failure.
Cache related issues. Since this works post a trigger refresh.
Appreciate your inouts on this. We even tried latest fixes which doesnt help and for testing purpose uninstalled the latest fix and edited the trigger then it works.