Universal Messaging --> Synchronisation of documents to UM

, ,
1

Hello,

I have a question related to UM. Before with broker i was using the below service to push the publishable documents to broker.

wm.server.ed:submitMany

I want to know if for UM we have an equivalent SAG service that I can call in my flow or java service.

Thanks in advance for your help.

Kind Regards,
Munish

2

Did you explore WPublic and WmRoot packages? If not you have to write your own code API using the java API reference w.r.t to UM

3

As UM will support the broker-based model, i think there won’t be any issue.
However, i have never used the service which you mentioned.

But as per my observation, there is no relation between UM and syncing of publishable documents with provider.

To understand this, i have done the following steps

  1. designed a broker based model with UM
  2. tested with deliver and publish mechanisms and everything is working fine (publishable document is inSync with provider)
  3. now modified the publishable document locally (structural change and new field additions)
  4. without syncing this modified publishable document with provider, re-tested the same cases.
  5. And observation is, i’m able to see data with my modifications at subscribing side.

But from my side, need to find about the syncing behaviour in UM from WM documentation.

1 Like
4

Hi Punith,

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.

Hope this helps.

1 Like
5

Hi Jonathan,

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.
publishable doc properties with protocol buffer.JPG

1 Like
6

Hi Punith,

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.

Hope this helps.

1 Like
7

Hi Jonathan,

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.

Note:
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’
java.lang.reflect.InvocationTargetException: UM_MIGRATE_NO_BROKER_TRANSORT

We doubt of the belwo things but not sure exactly which one is causing this issue.

  1. ENcoding type
  2. Presence of lex opr. We presume, it will hit us in performance but not sure its reason for the subscribing failure.
  3. 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.

Env : 9.10.

//Sabarish

8

Hi Sabarish,

UM_MIGRATE_NO_BROKER_TRANSORT means there is no Broker available. To run the utility service, broker must be connected to IS