SonicMQ settings in WebSpeed.

The setting is used to determine whether each agent connects separately to SonicMQ or whether a shared connection is used when using the -SMQConnect parameter. Earlier versions of Progress/OpenEdge only offered broker-connect, hence you won't see this check-box in earlier versions.

This topic was discussed at Exchange and the presentation & sample code can be downloaded here: http://www.psdn.com/library/entry.jspa?externalID=5279

This setting applies to both WebSpeed & AppServer. More information can also be found in the documentation - OpenEdge Application Server: Administration (which covers the administration of both WebSpeed & AppServer).

As a general rule, you'll probably want to enable this setting and use -SMQConnect. Used together, the benefits include: no need to configure the Sonic 4GL Adapter, fewer processes being started meaning decreased memory & processor usage, support for fault tolerance & client persistence, single client persistence store per broker.

The only reason that you wouldn't want to use -SMQConnect is if you're using OpenEdge on a platform that doesn't support Sonic (which is rather rare).

Using -SMQConnect without enabling ServerConnect does not gain anything and is a waste of resources and should probably never be used.

Oh yes,

I had seen this earlier but just gone out of my mind.

I have a confusion.

How do I distinguish whether the code is doing a ServerConnect or a BrokerConnect?

The code for both seems the same.

Thank you.

Three simple rules:

1. A connection established without the -SMQConnect parameter will use BrokerConnect.

2. If -SMQConnect is used, ClientConnect will be used.

3. The exception to rule 2 applies for WebSpeed or AppServer agent connects with -SMQConnect, where the SonicMQ ServerConnect check-box is checked (true). In this case, ServerConnect will be used.

Note that there is no coding difference between options 2 & 3, it's purely a WebSpeed/AppServer Broker configuration (and even then, it's one simple check-box).

HTH

And if I had no access to the code and still wanted to know what type of Connect is being used, is there a way? I mean seeing some logs?

Thank you again.

If BrokerConnect is being used, you would see it in the code. If you don't have the code, it should still be fairly simple to figure out, because there must be a "SonicMQ Adapter" configured somewhere, which of course has a log file.

To determine if ClientConnect or Server connect is being used (you wouldn't see it in the code), you can simply look whether SonicMQ ServerConnect is enabled in the Progress Explorer. You could also look in the appropriate broker log file for something like:

P-007524 T-L-3090 2 UB Basic OpenEdge Adapter for SonicMQ ServerConnect started: C:\Progress\OE101C\jre\bin\java.exe ...

Would like to study more on ClientConnect, ServerConnect and BrokerConnect.

Is there any more documents on this apart from the - Application and Integration Services ?

If you installed the OpenEdge documentation, you can search all the documents at once using Edit -> Search (not Find). Make sure that "Where would you like to search?" is set to "In the index named oeidx.pdx", but this is probably the default anyway.

The string "ClientConnect" is found in:

- OpenEdge Development: Messaging and ESB

- OpenEdge Application Server: Administration

- OpenEdge Getting Started: Application and Integration Services

Happy reading

Thank you Jamie, for that help again,

I would like to know one another thing.,

The code for ClientConnect and ServerConnect seems to be this,

=====================

RUN jms/jmssession.p PERSISTENT SET hSession

("-SMQConnect").

RUN setBrokerURL IN hSession("tcp://SonicServer:2506").

RUN beginSession IN hSession

=====================

where we inevitably seem to set the Sonic broker's URL,

I came to know that we could set a default broker in the ubroker.properties file, but I would preferably like to have the broker's URL set dynamically and not set it in the code at the client side.

Am I correct and is it possible to set it somewhere in the properties of the AppServer?

I'm not sure if I understand correctly... I don't believe there's a way to set the Sonic connection string as such in the ubroker.properties file.

The sample connection code looks fine, though you will need to make sure that you also set the appropriate username and password if you have security enabled.

Of course, you should never hard code the connection string into a program. It would typically be read out of a database, a configuration file, a parameter (-param) or (if you really must) an operating system variable.

I'm not sure what you mean about setting it "in the code at the client side". The connection program will only be deployed to the WebSpeed machine, so it's not "client side" in the sense of being able to be changed by any user. They would need to be able to change the code and write the new version out to the WebSpeed agent's propath.

I see now that the question now relates to AppServer, not WebSpeed. All the above is still 100% correct, but there's a little more if we're now talking about AppServer.

If you were to run your given connection code on the client-side (ie, not on the AppServer), each client will connect separately to SonicMQ. Since the connection wouldn't from an AppServer agent, ClientConnect will be used. In this case, the connection code would indeed to execute on the client-side, but the connection string could be centrally managed and read by the client from a server-side database or configuration file (probably through an AppServer call).

ServerConnect will only be used if the connection to SonicMQ is instantiated from the AppServer agent.

There are advantages and disadvantages to consider when deciding whether the client should connect to SonicMQ or the AppServer agents. Here are a couple:

- Messages with large contents that are read from the database will benefit from sending to SonicMQ from the AppServer (no need to send the whole message to the client)

- Request-reply messages sent from the client will block the client until the reply arrives

- Request-reply messages sent from the AppServer can allow the client to continue processing if the AppServer request is invoke asynchronously

- Messages sent to the application in general are best handled by the AppServer, as there may be no clients active at any given time

- Messages intended for a particular client of the application cannot (easily) be received by the AppServer, as it has no way to notify the client of the message's arrival