WARNING : before migrating from broker to UM

, ,
1

Hi,

just a warning to whoever would want to migrate from the broker to UM;

We migrated from the broker (8.2s version) to UM(9.8). We are NOT using ‘advanced’ features, really just simple publish/subscribe model.
SAG said that the switch from the broker to UM would be just a switch (simple click), that everything was backward compatible.
(they don’t use their own product, don’t believe what they say)

So we switched to UM and started publishing / consuming documents, everything worked in appearance.
We had a bad habit when we were using the broker; we though that by publishing 1 document, we would have the triggers consuming it once. It is not true with UM.

So after a while with UM, we are seeing a lot of cases where the subscriber will get the SAME document more than once.
After going through the documentation, it appears that we have to expect duplicates sometimes (if the IS failed to ‘acknowledge’ the document, it will be resent to the trigger (when the trigger is reloaded, when the JMS_CONNECTION to UM is reestablished, when the IS is restarted…)

For most of our process, it is not a big deal (a bit of a overhead), but for other processes, it is a BIG problem.

There is a way to avoid duplicates by configuring the ‘Exacly Once’ functionalities in the IS trigger
(basically, an integration server side document logging & comparing ).
It is not pretty, and I am not sure how it will scale with time (as we have a lot of documents), but it works.

Another comment : by upgrading to UM, you will loose the MWS visibility to the documents in the queue
;
with the broker you could go to MWS’s messaging menu and view/change documents published, not possible with UM; you have to
open enterprise manager and activate trace for debugging. It is also not possible* to see the number of documents pending (ex: when a serial trigger is consuming 1 document at the time, you could monitor the queue size from the broker’s API, not possible with UM)

*feel free to tell me how if I’m wrong.

I hope this will help somebody.

Good luck

2

Hi Jonathan,

for the first part about documents being processed more than one time:

This can occur with Broker too.

You should check if the Package WmPRT as welll as the normal triggers are configured for “Duplicate Event Detection” or “Document History”.

By doing so the IS is able to determine if the message has already been processed in the last 2 hours (the defaullt, but can be customized).

Regards,
Holger

3

Hi,

a new knowledge base article has been posted to Empower today referring to the duplicate event issue:
https://empower.softwareag.com/sl24sec/SecuredServices/KCFullTextASP/viewing/view.asp?KEY=124035-6572442&DSN=PIVOTAL&DST=TCD&HL=1&QUERY=|KB #: 1774513 Universal Messaging - Duplicated requests

Regards,
Holger

4

FYI:

Description:

Duplicate requests from UM are being received. Within the logs a reconnection on the link with the client is observed.

When communicating with a user and it reconnects internally, it re-sends all requests? Is there any way to fix it?

Resolution:

This is a designed feature. If the client does not acknowledge the event, when the connection is lost the event is rolled back. On reconnect they receive the event again.

This is not a bug but actually a requirement for transactional reading. To avoid this behavior, then the only possible solution is not do transactional reading.

5

Jonathan,

I’m sorry to hear about your experiences switching from Broker to UM. I’d like to assure you that we (Software AG) have put a lot of effort into ensuring maximum compatibility and as smooth a migration as possible. You should not have to make any code changes to your existing integrations, both JMS or native pub-sub. But you also need to realize that UM is a different product, so a level of testing and familiarization is key.
Regarding a couple of the points you bring up:
DUPLICATES
As mentioned already in this thread, there is no difference between Broker and UM regarding duplicates. Under normal circumstances, you will not get duplicates. If you suffer from outages of servers or network, then messages may be resent if transmission was interrupted. This applies equally to both Broker and UM. If you have been seeing different behavior, then there may be some misconfiguration or other problem.
ADMIN UI
UM is administered using Enterprise Manager. Version 9.9 and higher shows numbers of pending messages for triggers in the Named Objects tab for a channel. In the upcoming 9.12 release (due out in October 2016), we have rich web-based administration of UM in Command Central, including a single view of all triggers (durable subscribers), along with numbers of pending messages.

Thanks again for your feedback and do let me know if you have other questions.

Jonathan Heywood
Software AG Product Management

6

We had lots of issue with UM 9.8 and had to go back to broker for our critical environment. Kept UM for other environment not so critical one. UM puked on us yesterday after restart of the environment, delivering all processed and acknowledged documents as old as of 10 days back, created major havoc to the business. Never had this issue ever before with Broker. We are using basic native pub/sub nothing fancy.
We are in a big soup now!!!

7

The delayed redelivery of documents is a known issue and it is resolved in UM 9.8 Fix 9 (and higher), as well as similar fixes for other versions. Please apply that UM server fix and the associated UM client, shared lib and common bundle fix to IS.

8

Hi , I would like to know if our IS is on 9.10 , can we install UM on 10.1 and messaging will work seamlessly. I couldn’t found the documentation to refer backward compatibility !! thanks in advance

9

Rohit,
You can connect IS 9.10 to UM 10.1 for JMS, but if you use native pub-sub from IS, this is not supported.
Note that this only applies to the core JMS functions (pub.jms:* and JMS triggers). You cannot use the “manage destinations” option to create queues and topics from Designer in cross-version scenarios.

1 Like
10

Thanks Jonathan for quick reply. highly appreciated. Can you please suggest the documentation link to refer the IS UM Versions compatibility so that we can plan accordingly. .

Also is UM9.10 trial version available for poc or only latest can be downloaded.

11

Rohit,
the version compatibility is not well documented and we are currently working on improving it.
Regarding trial for UM 9.10 - assuming you are a Broker customer, you can install UM 9.10 using Installer - it should be visible for you. You can leave the License field empty to activate a 90-day free trial of UM.

12

Hi Rohit,
Have you swapped some of your Broker licenses for UM licenses? If yes then I would assume you should see the ability to download the appropriate version of UM from Empower.
From a trial version point of view we always use the latest as we would want people to make use of the latest features and fixes in the product.
Regards, Jane.

13

Jonathan,

We have tons of triggers with lexical filtering. Is it true that UM doesn’t support $null filtering? See below example. We have over 600 plus triggers and if we had to categorize them, 75% has filtering where it check for $null. Does the migrate utility support this filtering?

Example: %rootDoc/field1% L_EQUALS $null

14

UM supports explicit null check in filter. So, does IS.
Migration utility must support it. If it doesn’t, then it is a bug.

15

Hi Rohit,

Based on the above theory are you planning to use UM 9.10 or 10.1 version in your IS 9.10 landscape?

HTH,
RMG