Does the PAS for OE supports JMS out of the box?

Hi Valeriy,

We do not support anything related to JMS out of the box for PASOE.

For your-use, I think you can run an asynchronous procedure in an agentStartupProcedure which would subscribe to the Queue in MQ and do the respective actions.

Hi Irfan,

Thank you! Where can I find an example of such a procedure?

Regards,

Valeriy

Hi Irfan,

Hi Marian,

I haven't tried this use-case, so not sure if that might go into issues or not. The assumption is that I can always keep one session busy listening to  the JMS Queue. I can give a shot and see how it works.

Hi Irfan,

[quote user="Irfan "]

For your-use, I think you can run an asynchronous procedure in an agentStartupProcedure which would subscribe to the Queue in MQ and do the respective actions.

DEFINE INPUT PARAMETER inputParam AS CHAR.

DEFINE VARIABLE ptpsession AS HANDLE.

DEFINE VARIABLE replyMessage AS HANDLE.
DEFINE VARIABLE consumerH AS HANDLE.

define var      BrokerURL     as character no-undo.
def    var      Is_connected  as logical   no-undo.

BrokerURL = "tcp://172.16.95.131:2506".

run jms/ptpsession.p persistent set ptpsession ("-SMQConnect").
run setConnectionURLs in ptpsession (BrokerURL).
run setReconnectTimeout in ptpsession (600). /* in minutes */
RUN setReconnectInterval IN ptpsession (10). /* in seconds */
run setPingInterval in ptpsession (5) .
run setFaultTolerant in ptpsession(false).
run setNoErrorDisplay in ptpsession (true).
run setUser in ptpsession ("Administrator").
run setPassword in ptpsession ("Administrator").

do on error undo, leave:
    run beginSession in ptpsession.
    Is_connected = true.
end.

if   Is_connected then
do:
	RUN createTextMessage IN ptpsession (OUTPUT replyMessage).

	RUN createMessageConsumer IN ptpsession (
                              THIS-PROCEDURE,    /* This proc will handle it */
                             "requestHandler",  /* name of internal procedure */
                              OUTPUT consumerH).

	RUN receiveFromQueue IN ptpsession ("PASQ1",   /* request queue */
                                     ?,               /* No message selector */
                                     consumerH).      /* Handles the messages */

	RUN startReceiveMessages IN ptpsession.

	RUN waitForMessages IN ptpsession ("inWait", THIS-PROCEDURE, ?).

end.
else 
do:
    message "No connection to the broker!". pause 0.
end.

PROCEDURE requestHandler:
	DEFINE INPUT PARAMETER requestH AS HANDLE.
	DEFINE INPUT PARAMETER msgConsumerH AS HANDLE.
	DEFINE OUTPUT PARAMETER replyH AS HANDLE.

	DEFINE VAR replyText AS CHAR.


	/* Creates a reply message. The reply is sent automatically when control
	   returns to the 4GL-To-JMS implementation.
	*/
	replyText=inputParam + " executed " + DYNAMIC-FUNCTION('getText':U IN requestH).
	message replyText. pause 0.
	RUN deleteMessage IN requestH.
	replyH = replyMessage.
	RUN setText IN replyH (replyText).

end.

FUNCTION inWait RETURNS LOGICAL.
	RETURN true.
end.

I used the code from the example of documentation, OpenEdge® Development: Messaging and ESB (example21.p), Messaging Examples topic.

Then define this procedure in agentStartupProc and restart the server. To test the listener I used example20.p from the same documentation. At first glance everything seems to be working fine.

Nevertheless, it may be necessary to add something to a procedure (JMSServerExample.p) for better performance and reliability? How do you think?

Regards,
Valeriy

PASOE supports the Sonic Adapter using Broker Connect. You need to have Sonic installed as well as the Sonic Adapter for OpenEdge.

Both Classic and PASOE AppServer are not designed to process JMS messages without creating a backdoor. If you want to listen to messages and send them to an AppServer for processing, you should use a batch client that calls into the AppServer. Or, the ESB Adapter was another way we provided this support. No difference here between PASOE and Classic, and you certainly shouldn't create calls out to the MQ Adapter in an Agent Startup proc.

batch client - dispatch to AppServer. This is the proper architecture. Everything else creates a backdoor and bypasses security and will cause heartburn even if you get it working. Both Classic and PASOE would need a long running orphan session in order to process incoming messages.

You understand your agent startup proc never returns. Surprised it actually works, but certainly not supported.

Hi David,

Thank you for your clarification!

Yes, I have noticed that my procedure is not completed after stopping agent. I had to manually kil that session.

Do I understand correctly that the listener architecture should look like this:

1. Run the batch process, which will start my ABL-program (JMSServerExample.p with small modifications), for example by cron.

2. Once the process receives a message, it calls the procedure on an application server to process the message and waits for the result.

3. Once the result is received, the process sends a response to queue in ESB.

In this architecture, I do not understand how to stop the work the batch process.

I'm new to this.

Maybe there are some ready examples to see how to implement it.

Regards,

Valeriy

Where can I find an example of configuring and using Sonic Adapter for OpenEdge on PASOE?

Valeriy,

Hi Marian,

Thanks for the advice!

I'll think about it.

Regards,

Valeriy

Valeriy,