Universal Messaging 10.5 | Migrating webMethods Broker to Software AG Universal Messaging Documentation | Migrating from webMethods Broker to Universal Messaging Guide | Migrating from Broker to Universal Messaging | Pre-migration Considerations | Broker Considerations
 
Broker Considerations
The following table lists the differences between Broker and Universal Messaging that you must consider before migration.
Broker
Universal Messaging
Recommendation
webMethods Messaging on an Integration Server supports connecting to only one Broker instance.
webMethods Messaging on an Integration Server supports connecting to multiple Universal Messaging server instances. This increases the scalability of the messaging platform.
During migration, individual Broker instances in a Broker Server can be migrated to a single or multiple Universal Messaging realms.
Broker uses My webMethods Server for administration.
Universal Messaging uses Enterprise Manager for administration. Software AG Command Central can also be used to administer and deploy Universal Messaging.
The functionality differs for Universal Messaging. Refer Universal Messaging Administration section for more information.
Broker supports Territories and Gateways.
Universal Messaging supports equivalent functionality through Zone and Static Joins.
For more information about how Universal Messaging uses Zone and Static Joins, refer to Universal Messaging Zone and Static Joins.
Broker clients native messages are encoded by Integration Server using IData.
Universal Messaging uses the Google Protocol Buffer (protobuf) for the native messages.
Some of the Broker field names do not have the exact equivalent syntax which is available in Google Protocol Buffer field name. For information about how Universal Messaging uses Google Protocol Buffer (protobuf), see Google Protocol Buffer Specification.
Broker supports filtering with standard comparison, arithmetic operators, bitwise operators, string operators, and standard operator precedence. Also, Broker filters support regular expressions, hints, and some in-built functions.
Universal Messaging also supports filters, along with its extensions.
Some Broker filter extensions does not have equivalent functionality in Universal Messaging. For information refer, Filtering.
Refer "Event Filtering" section in Universal Messaging Concepts Guide for more information on filtering.
Broker supports XA transactions (2 phase commit).
Universal Messaging does not support XA transactions.
In most of the cases, you can workaround the XA limitation by analyzing your transaction boundaries and by using the last resource commit optimization. For more information on XA transaction, refer webMethods Integration Server Administrator’s Guide.
Broker supports message priority.
Universal Messaging provides limited support for message priority. It prioritizes messages on the client, which means that the messages may not be prioritized as you expect.
However, in Universal Messaging you can use the alternate approaches. For instance, you can use multiple topics for specific priority and preferentially consuming the messages from the higher-priority topics.
Broker supports individual subscription pause when the corresponding Integration Server trigger is paused.
Universal Messaging does not completely support pausing individual subscriptions.
Pausing a Integration Server trigger with Universal Messaging can cause duplication of messages. For information on how the Universal Messaging works with limited support on pausing individual subscriptions, refer Pause Integration Server Triggers .
Broker supports Document Logging for auditing and resubmitting documents.
Universal Messaging does not support Document Logging.
For Universal Messaging, you can use Integration Server Service Flow auditing functionality to achieve the same.
For more information see, "About Service Auditing" section in Software AG Designer Online Help.
Broker supports Dead Letter Queue.
Universal Messaging also supports the Dead Letter Queue. However, the functionality differs.
For more information on Dead Letter Queue, see Dead Letter Queue.
Broker supports horizontal scalability using Clustering with commonly used Round Robin policy.
Universal Messaging supports horizontal scalability which is used in Round Robin JMS Cluster policy for Broker.
For information on how differently Universal Messaging uses horizontal scalability see, Horizontal Scalability.
Broker supports high availability using the Mutlisend cluster policy.
Universal Messaging supports Active/Active cluster to provide high availability.
For more information, see "Clustering" section in Universal Messaging Administration Guide documentation.
Broker supports proprietary Java, C#, and C API libraries.
Universal Messaging also supports proprietary Java, C#, and C API libraries. But, the exact interface definition differs.
Ensure to verify all your custom client applications that make use of Broker Java, C#, C APIs and plan the migration.
Universal Messaging Administration
Universal Messaging uses Enterprise Manager as its administration and monitoring tool. Enterprise Manager can run remotely and manages multiple Universal Messaging servers. Enterprise Manager uses Universal Messaging Administration APIs, similarly for Broker, My webMethods User Interface uses Broker Administration APIs. If you have custom Broker administration clients, you need to rewrite that client using Universal Messaging Administration APIs.
In addition, Universal Messaging also supports JMX API.
Universal Messaging Zone and Static Joins
Brokers can be linked to form units known as territories. Territory gateways are links that you establish between territories. Now, the territories and gateways are replaced with Universal Messaging Zones and Universal Messaging Joins respectively. Therefore, you can establish a similar messaging topology with Universal Messaging or you can review and simplify your messaging landscape when you migrate.
Universal Messaging administration and monitoring support for a large number of topics and queues are limited, so you must plan carefully and consider changing your topology. Universal Messaging Zones and Static Joins are implemented differently in Universal Messaging. During the migration you must ensure to understand and accommodate to these changes. For example, to set up request-reply across Universal Messaging servers, you need to perform additional steps for creating required topics and queues.
Google Protocol Buffer Specification
Google Protocol Buffer Specification provides a simple and performant serialized format for transporting data across the network. The Google Protocol Buffer specification contains support for a limited character set. Hence, ensure that the names and fields in your document comply with the protobuf spec https://developers.google.com/protocol-buffers/docs/reference/proto3-spec.
Further issues related to using the protocol buffer encoding type are available in the section "Using Protocol Buffers as the Encoding Type" of Software AG Designer Online Help.
The following are the commonly encountered issues:
*Spaces- Spaces appear in your document or field names. Remove the spaces if it is not required.
*@- The @ character may appear in your document or field names which can cause warning messages. Remove this character if it is not required.
*Colons(:)- Integration Server uses colons for XML namespace identification. If you do not use XML, change them to protobuf acceptable characters. Or, if you are using XML, then it would assess the impact on performance of performing the client side filtering rather than server side filtering.
Filtering
The migration utility pub.utils.messaging:migrateDocTypesTriggersToUM attempts to migrate the filter to a Universal Messaging (provider) filter. However, this process is not always achieved. Sometimes, the filter definition from Integration Server or Broker may not meet the SQL/92 filter standards supported by Universal Messaging. Also, the filter definition from Integration Server or Broker uses some extensions that are not supported by Universal Messaging. This can be a considerable task if there are large number of clients and flow services in the affected document types.
If you find any errors or warning while running the pub.utils.messaging:migrateDocTypesTriggersToUM utility for the field names and identifiers, rename the fields to valid identifiers for Google Protocol Buffers and perform the migration for the affected documents and other objects.
In conjunction with Designer, Integration Server also supports the ability to search for a particular variable and identify all references to that variable in other assets, such as flow services, document types, specifications, and triggers. You can selectively or globally replace a particular variable name with another variable name. This can considerably reduce the effort required to rename the fields. Perform a back-up for all the affected packages before you refactor.
You can still continue to use the same fields without renaming, but these fields are migrated with filters as Integration Server (subscriber) filters. However, large number of triggers having different filter criteria can potentially impact Integration Server processing. Make sure these filters are working and are verified with a load similar to that expected in the production.
Important: 
*If migration utility pub.utils.messaging:migrateDocTypesTriggersToUM fails to migrate Broker's server side filters to Universal Messaging server side filtering, then it is mapped to client side filtering. This may impact the performance.
*Broker filters also support regular expressions or hints such as IncludeDeliver, LocalOnly, DeadLetterOnly, and some functions like substring, toDouble, toUpperCase, etc. These may not have an equivalent mapping in Universal Messaging. In your migration, you must factor in the impact of such in-frequently used Broker filter extensions.
Comparison of filter operators in Broker and Universal Messaging
Refer to the below tables to find the full list of compatible and non-compatible filter operators.
The following table shows the comparison of arithmetic filter operators:
Operator name
Broker filter
Universal Messaging filter
Addition
+
+
Subtraction
-
-
Multiplication
*
*
Division
/
/
Modulo
%
Unsupported
Unary minus
-
Unsupported
The following table shows the comparison of relational/comparison filter operators:
Operator name
Broker filter
Universal Messaging filter
Equal to
=,==
=
Not equal to
!=
<>
Greater than
>
>
Less than
<
<
Greater than or equal to
>=
Unsupported
Less than or equal to
<=
Unsupported
The following table shows the comparison of logical filter operators:
Operator name
Broker filter
Universal Messaging filter
Logical negation
!, not
NOT
Logical AND
&&, and
AND
Logical OR
||, or
OR
The following table shows the comparison of bitwise filter operators:
Operator name
Broker filter
Universal Messaging filter
Bitwise NOT
~
Unsupported
Bitwise AND
&
Unsupported
Bitwise OR
|
Unsupported
Bitwise XOR
^
Unsupported
Bitwise left shift
<<
Unsupported
Bitwise right shift
>>
Unsupported
The following table shows the comparison of string filter operators:
Operator name
Broker filter
Universal Messaging filter
String concatenation
+
Unsupported
Equal to
=
Unsupported
Equal to
==
Unsupported
Not equal to
!=
Unsupported
Greater than
>
Unsupported
Greater than or equal to
>=
Unsupported
Less than
<
Unsupported
Less than or equal to
<=
Unsupported
For more information on filters in Broker, see webMethods Broker Client Java API Programmer's Guide. For more information on filters in Universal Messaging, see Universal Messaging Administration Guide.
Pause Integration Server Triggers
For Universal Messaging, pausing Integration Server triggers frequently can result in duplicate messages at triggers. During trigger pause, Integration Server can cease subscribing and then re-subscribe. This can disrupt the acknowledgement flow to Universal Messaging which can result to a message re-delivery. Ensure that your applications are aware of the messages and event IDs to detect duplicate messages.
Dead Letter Queue
For Dead Letter, processing the events in Broker without any subscription or failed filter condition results in Dead letter queue.
In Universal Messaging, the events move to dead event store when they are removed by Universal Messaging realm, for cases such as, channel capacity, channel TTL, event TTL.
Horizontal Scalability
Horizontal Scalability in Universal Messaging allows the clients to seamlessly publish and consume events from multiple independent realms and clusters using a single connection. It is available for both the Universal Messaging native API for Java and the Universal Messaging API for JMS. It is enabled by using the horizontal scalability URL syntax. For information, refer Universal Messaging Administration Guide documentation.