I had a few questions about migrateDocTypesTriggersToUM service if anyone could help me out:

1). How would the triggers be migrated automatically.

2). What about the trigger setting -serial/concurrent processing.

3. For retry service invocation, how would it be done in UM, which trigger has been supporting from Brokers.

Thanks!
John

I believe UM migration tool will handle these configurations move as a whole and adjust the settings accordingly. Are you using that tool option or any manual methods found?

HTH,
RMG

We are planning to use that tool since we have so many items to update. I would rather do it in one sweep than one at a time.

I was just curious about documentation on the service and how it handles those three questions

John,

the basic step you need to do to switch from Broker to UM is this:

• Create a wM messaging alias, pointing to UM
• Set it as default
• Optionally run the migrateDocTypesTriggersToUM service
• Sync all publishable doc types

The migrateDocTypesTriggersToUM service will update the doc types to use protobuf encoding and will update any trigger filters to the correct syntax for UM. If you are migrating all doc types at once, then you leave the package list empty and the messaging alias empty.
If you want to do things in a phased approach, then set the packages/doc types you want to switch, and provide the new wM messaging alias. In that case, also don’t set the UM messaging alias as default - this will leave unmigrated doc types using Broker.
Serial/concurrent settings will be migrated and will behave the same way (if your target is UM 9.9 or higher).
Service retry settings also behave exactly the same way with UM as with Broker.

In fact, if you don’t run migrateDocTypesTriggersToUM, then everything will work with UM, but performance will not be optimal if you use trigger filters. So it is not actually a required step.

One more thing: the migrateDocTypesTriggersToUM service has a report-only mode (default), which will report what updates it would do before changing anything. You need to set report-only to FALSE to actually update the doc types and triggers.

For more info, please see [url]http://techcommunity.softwareag.com/ecosystem/documentation/webmethods/wmsuites/Migrating_from_Broker_to_Universal_Messaging.pdf[/url]

Hi John

I recommend you listen to this webinar on Migrating from Broker to Universal Messaging:
http://techcommunity.softwareag.com/pwiki/-/wiki/Main/Migrating+from+Broker+to+Universal+Messaging

This webinar is as of wM 9.9 but covers everything you need to know about migrating Broker to UM.
This webinar also refers you to this document:
http://techcommunity.softwareag.com/ecosystem/documentation/webmethods/wmsuites/Migrating_from_Broker_to_Universal_Messaging.pdf
This doc is also very informative and covers the utility pub.utils.messaging:migrateDocTypesTriggersToUM

I hope this helps.

Regards
Wayne

Thank you everyone. This is very helpful

Hi Jonathan,

I have a small doubt. I didn’t run the utility service pub.utils.messaging:migrateDocTypesTriggersToUM which you have mentioend as optional in your migration steps, I am able to see warnings like " No condition matches in trigger - for publishable doc Types" is this anyway related . Will running the utility service eliminate these warning messages. I understand that running the utility service will change the lexical operators present in the triggers to use server side filtering.

Another issue is somestimes when the UM is restarted, the triggers have to be refreshed everytime and only then the documents are getting subscribed. Can you think of something we might have done wrong ? is this normal ?

Warm Regards,
Aravind Mohan

Aravind,

what you are seeing is expected. If you don’t run the utility, then all filtering takes place in IS (where previously it would take place in Broker). That is why you see those warning messages. But the actual messages reaching the triggered service will be the same.
The performance difference is due to every message for a doc type being passed from UM to IS, instead of the trigger filtering taking place in UM, which is more efficient.
Running the utility modifies the doc types and triggers to ensure that the filtering takes place in UM, hence improving performance.

Regarding the issue you are seeing on restart, please make sure you have the latest IS and UM fixes installed, including the UM common libraries and shared bundles fixes on each connected IS. There have been some fixes to address that in various releases.

Hey Jonathon,

            We have initiated efforts to upgrade WM-Broker to Universal Messaging. I just needed some more service/trigger level questions answered please.

1. Services/Triggers with upstream and downstream apps.
2. Scheduled or on-demand.
3. Daily volume and average message size.
4. Any direct object references used while building services and/or triggers e.g.
   a. Directly referencing any folder on specific HDD.

Be aware of the trigger filter. The unity will NOT migrate filters with reg-expressions and possibly some other complicated ones. You’ll see them in the updatedTriggersWithWarning list. We’ll need to figure it out and migrate it manually.

Hi Jonathan,

I continue the same issue “Arvindh” explained in this thread.

We have problem with the service “pub.utils.messaging:migrateDocTypesTriggersToUM”, as we ended with teh below error. Currently checking for the releveant jars hindering this service run in our env, appreciate your help on this.

Could not run ‘migrateDocTypesTriggersToUM’
java.lang.reflect.InvocationTargetException: UM_MIGRATE_NO_BROKER_TRANSORT

Also, we followed your above said approach with no broker alias in new environment 9.10 with only UM connected (old is wM9.5 with broker). Question is, do we have to create a broker alias in the new env and use it in the migration service?

Thanks!

Sabarish, are you making Universal Messaging your only messaging provider in your new 9.10 environment OR are will you be migrating in phases (use both UM and Broker) ?
If you look at the UM migration guide (http://techcommunity.softwareag.com/ecosystem/documentation/webmethods/wmsuites/Migrating_from_Broker_to_Universal_Messaging.pdf) you will see two these two approaches mention starting on page 25. For approach one (UM only) you only need a connection in IS to UM. For approach two (UM and Broker) you need connections in IS to UM and to Broker.

Please clarify the approach you are using.

–Wayne

Wayne,

We have only UM as a messaging provider in our 9.10. Its only IS to UM connection.

Post deployment of a pacakge with triggers the subscription is not happening. But when the trigger refreshed thru designer it works. It is strange, but happening for most of the triggers.

Appreciate your inputs.

//Sabarish

Hello Experts,

Where in the UM Enterprise Manager can we see the trigger and the filters?

Regards,
Mayank

I think it should be another thread but… In UM 9.9 there is no such possibilty in the EM, you have to write a program using Admin API to display this. In later versions of EM (don’t know exactly, which one is the first having this) you should be able to see it in the Named Objects or in the Connections tab.

Hi all,

We’re also evaluating whether to migration to UM.

I’m getting the error message: [ISS.0086.9366] Error retrieving Broker Transport when trying to run the migrate service.

Our DEFAULT_IS_JMS_CONNECTION is enabled (no SSL) and connected to our Broker. Our IS_UM_Connection is enabled (NSPS) and connected to a UM cluster.

Anybody know what I could be doing wrong?

Tx

Hi,

Configure a secondry connection to broker in your target IS where you run the migration utility.

The broker should be the same one configured in your old server where you migrate from.

Gud Luck!

//Sab

Hi Sab,

Thanks a lot for the inputs! We are actually testing the migration from Broker to UM first, the IS migration will come later.
So we have no source and target IS, just one connected to both broker and UM.

Any ideas?

Thanks,

Loic

Hi Loic,

on the IS, you need to have (at least) two wM Messaging connections configured: one to Broker and one to UM. As soon as you have run the migration service, you can remove the Broker connection if you want.

Hi Loic,

Hope you are running the service “pub.utils.messaging:migrateDocTypesTriggersToUM” meant to migrate the messaging entities Topics, queues, doctypes to the connected default UM.

If this is not the case, which service are you invoking?

//Sab

Hi Sab and Jonathan,

Really nice to see you help out so quick!
We have one IS in the setup. The IS is connected to both broker and UM.

Yes, I am using the service pub.utils.messaging:migrateDocTypesTriggersToUM as indicated in the migration guide.

thanks for the inputs,

Loïc

Loic,

your earlier post said you had a JMS Alias pointing to Broker. This is not what you need for this utility. You must have a wM Messaging connection (not JMS) connected to Broker. It doesn’t need to be the default connection, but must be present.
Do you have that?

Hi Jonathan,

Yes this is the correct setup. However, I think that is where there was a problem: I disabled the Broker connection alias, but I couldn’t get it to enable again - IllegalStateException.
I had to reconfigure the connection.

I now test ran the migration service again and it now executes fine.

Thanks for the help!

Loïc

Loic,

good to hear!

One little gotcha: by default the service runs as reportOnly, which only reports what changes it would make, but doesn’t update any assets. You need to set reportOnly to false to get it to actually update doc types and triggers.
(If you read the doc, it should be clear, but a lot of people miss that!)

Cool, thanks for the tip, indeed I hadn’t picked that up yet.

Cheers,

Loic