Apama Basics: Sending/Receiving events/messages

,
1

Hi All,

These might be some common questions; but being new to Apama, just to make sure I don’t miss out on a simpler approach of doing things:

  1. Can we send messages from both UM queues and topics to Apama?

  2. How to send messages from UM to Apama - I have read about using the JMS Correlator-Integrated Adapter. Is this the only way, or others like triggers etc where we can specify Apama as the subscription?

  3. Sending events from Apama to UM - One approach is to use “send to ” in our EPL code. Any other way?

  4. How to subscribe to UM messages in Apama - I read about the monitor.subscribe(); method. Any other way out?

  5. Can we have an Apama query as the initial touchpoint to receive a UM message and start Apama processing? If yes, then how?

  6. Can an Apama query send events directly to UM using some method/construct?

I have gone through the Apama documentation, but just need some exact answers to proceed.

Thanks
Nishant

2

Please find answers to few of your queries, which I’m aware of:

#1. I think UM queue is not supported. But JMS queue and topics, both are supported.

#2 What you mentioned is one way for JMS messages. For UM native messaging, you can use “UM Messaging Transport” connectivity plugin. https://techcommunity.softwareag.com/ecosystem/documentation/onlinehelp/Rohan/Apama/v10-3/apama10-3/apama-webhelp/index.html#page/apama-webhelp%2Fco-DepAndManApaApp_the_universal_messaging_transport_plug_in.html%23

I think to subscribe messages from UM to Apama, only way is within Apama.

#3 Send … to … is only the way I know. Emit statements are there but will be deprecated.

#4 it is the only way I know while using Connectivity plugin.

3

Some more info:
#1 Using JMS, Apama can send and receive on both topics and queues with UM. Using the native UM client (UM messaging transport) Apama can only use topics, not queues.

#2 Not clear what the original question means. Apama is always a client when talking to UM. Not clear what is meant by triggers in this context.

#3 Yes you would always use the EPL “send … to …”

#4 Yes, subscribe the monitor to the channel, then set up a listener to the specific events.

#5/6 - Please describe the questions a little more. However, if you are new also to Apama, please be aware that the phrase “query” has special meaning, and I’m not entirely sure if you mean “query” or EPL in general. The main thing to remember is that everything in general in Apama is asynchronous. Incoming data comes in on a channel, and outgoing data goes out on a channel. Surrounding that, different pieces of connectivity might be delivering that data to or from other external systems, such as UM or some other messaging bus, or other remote system.

4

Hi Kevin,

Thanks for your responses. I have elaborated on the unclear questions below. Please suggest:

#2 By triggers, I meant WM broker or JMS triggers, where we can specify something like “Apama” instead of a subscribing service.
Looks like this is not the case. Still, please suggest.

4 Do we need the monitor.subscribe() statement in our monitor if we are using JMS correlator to receive messages; or only while using the UM connectivity plug-in?

#5 By query, I meant EPL query that does the same work as the EPL monitor. So my question is if we can have an EPL query receive messages from UM/other bus, just as the monitor does. If yes, what should we write in the EPL query to subscribe; just like we have monitor.subscribe() in case of monitors.

#6 Here also, I meant EPL query. I think we can use “send to” here also to send events to UM. Please confirm.

Thanks
Nishant

5

#2 By triggers, I meant WM broker or JMS triggers, where we can specify something like “Apama” instead of a subscribing service.
Looks like this is not the case. Still, please suggest.

You can publish JMS messages from WM using whatever mechanism you usually use to publish messages from WM.

From Apama, the supported ways of receiving messages are as a JMS client, using the UM connectivity plug-in, or using the Digital Event Services connectivity plug-in (which is the simplest way to get messages from wM Integration Server).

The WM concept of a JMS trigger doesn’t really make sense within the Apama correlator, where we have a simple, transport-agnostic and unified way to handle incoming events that is fully asynchronous (in line with concept of CEP). Just configure the JMS/UM/DES transport to receive the requried messages, then subscribe to the associated channel(s) from any monitors that want to see the data (that is if using UM/DES; if using JMS make sure your monitor isn’t running in a private context and you’ll get the messages without even subscribing to a channel).

4 Do we need the monitor.subscribe() statement in our monitor if we are using JMS correlator to receive messages; or only while using the UM connectivity plug-in?

No, JMS (for the time being) is an exception. Incoming JMS messages go to all public contexts automatically without subscribing, so provided you’re not using a monitor instance running in a private context that you’ve created you’ll be able to listen for incoming JMS events from any monitor. There’s nothing to subscribe to for JMS, just need to configure the the transport with the queues/topics to pull events from.

#5 By query, I meant EPL query that does the same work as the EPL monitor. So my question is if we can have an EPL query receive messages from UM/other bus, just as the monitor does. If yes, what should we write in the EPL query to subscribe; just like we have monitor.subscribe() in case of monitors.

For getting JMS messages from queries see http://www.apamacommunity.com/documents/10.3.0.1/apama_10.3.0.1_webhelp/apama-webhelp/index.html#page/apama-webhelp%2Fco-DepAndManApaApp_query_connecting_to_jms.html

For getting messages from UM/DES or any other connectivity plugin, you need to configure your transport to send messages into the correlator on the special channel name com.apama.queries, or alternatviely write a simple piece of forwarding EPL that subscribes to whatever channel the events are coming in on and forwards them to com.apama.queries. See http://www.apamacommunity.com/documents/10.3.0.1/apama_10.3.0.1_webhelp/apama-webhelp/index.html#page/apama-webhelp%2Fco-EplQueRun_comparison_of_queries_and_monitors.html

#6 Here also, I meant EPL query. I think we can use “send to” here also to send events to UM. Please confirm.

Yes you can use send … to … from a queries action just as you can from EPL, to send to JMS, UM/DES or other connectivity plugins.

6

Thank you all for your inputs…

Now about when to use correlator-JMS and when to use UM connectivity plug-in?

After going through the documentation, I found UM connectivity plug-in is better to use than the corrrelator-JMS option, since it can be used to connect different Apama components and integrate with non-Apama systems also.

While JMS provides reliable messaging.

I understand that in most cases it should be UM plug-in; but then where does these 2 fit the best…any use cases or guidelines?

Thanks

7

If you need reliable messaging or if you need mapping of messages containing XML you need to use JMS.

If those don’t apply we’d recommend using the UM connectivity plugin, which is liekly to be more performant, and also has better options for [non-XML] mapping e.g JSON.

We plan to bring them closer together in future, but not quite there yet.

8

Hi Nishant,

The two provide slightly different capabilities currently, both in transport features and content transformation.

The UM connectivity plug-in supports JSON decoding out of the box as well as messages with data stored in nEventProperties. It’s also somewhat easier to interact with from non-JMS senders using the UM API. For other decoding it’s very easy to write new connectivity codecs to decode different formats.

However, we have not yet added either support for reliable messaging or support for UM queues or datagroups, although there’s a sample datagroups plug-in available with the installation.

For JMS there is support for queues as well as topics and we support reliable messaging. It’s also got a built-in XML codec if your data is in that format.

In general if the connectivity plug-in works for you I would recommend that option, but many use cases require the features in the JMS interface.

Lastly, there is a third option if you’re connecting multiple Software AG products together, particularly IS and Apama which is Digital Event Services. DES provides an event type mapping layer over the top of UM and an efficient wire format for data interchange within the SAG suite. We do have support for reliable messaging within our DES connectivity plug-in.

HTH,
Matt

9

Thanks a lot for your responses…really appreciated

This has given me the confidence to design and implement Apama stuff using best practices.