connecting to Sonic ESB 7.6 from Maximo 7.1 or WebSphere 6.1 - Forum - Technology Partner - Progress Community

connecting to Sonic ESB 7.6 from Maximo 7.1 or WebSphere 6.1


connecting to Sonic ESB 7.6 from Maximo 7.1 or WebSphere 6.1

  • Hello,

    I am new to Sonic ESB and JMS, so please pardon me if my questions are a bit on the simple side. However, I'm happy to be directed to documentation or to provide further information about Maximo. I have been searching for a few hours and not found anything useful, which is why I am posting here.

    I need to connect to Sonic ESB 7.6 from Maximo 7.1. It seems to me that I may be able to connect directly, or I may be able to connect via WebSphere Application Server 6.1. I prefer to connect directly for simplicity's sake. So, assuming the direct approach:

    Maximo has the ability to work with JMS end points. When I try to set one up, it asks for a connection factory JNDI name and a context factory. What values or types of values do I need to give? Also, I'm assuming that I'll need to include some jar files in my class path. What are they, and where can I find them?

    Thank you for any assistance you can provide.

    Best regards,

    Jason Uppenborn

  • Look for some sonic samples related to the Jndi connection like JNDIChat. You will get all the information.


              java.naming.provider.url   = ''
              java.naming.factory.initial = com.sonicsw.jndi.mfcontext.MFContextFactory
              com.sonicsw.jndi.mfcontext.secondaryProviderURL = tcp://localhost:8080"
              com.sonicsw.jndi.mfcontext.idleTimeout= 60000

  • The one thing you want to make sure of is that you use the env variable for the domain.  You need this is the domain is not named the default "Domain1,  as a side note, in Sonic 8.0, you can add this to the connection URL.

  • Hi William,

    Can you tell me what the name of the environment variable is supposed to be?

    My customer's "Sonic person" has found a knowledge base article suggesting that we have to create a new domain called "Domain1" unless we can specify the com.sonicsw.jndi.mfcontext.domain= property somehow. Unfortunately, Maximo won't allow me to set this property, and perfharness, a free JMS load testing tool from IBM, won't let me set it either.

    Out of curiosity, would the v8 libraries (the .jar files) connect to a v7.6 ESB? If yes, what would need to be done from a licensing perspective to make it legal?

    Best regards,

    Jason Uppenborn

    Business Consultant

    Vetasi Limited

    +44/0 7958313050

  • Hi William,

    I understand with this post is that, when we get the context for the DS, we can specify the value as a env variable, like in this post is for the domain name i.e


    Is that is right? If yes,  i am just corious to know Is that feauture is provided by SONIC API's?

  • Yes.  You need to specify the com.sonicsw.jndi.mfcontext.domain.   There are other useful ones to set up for things like timeout and retry count.

    In 8.0, you can add these to the url -- that was done for cases where you could not set an env variable.   But you do need Sonic 8.0 (for the broker as well as the client).

  • sk185050 wrote:

    [snip]  when we get the context for the DS, we can specify the value as a env variable, like in this post is for the domain name i.e


    Is that is right?

    No.  You set the env BEFORE you get the context.  The env variable is needed to get to the correct DS.

  • What worked was creating a file in JAVA_HOME/jre/lib with that property in it. In the case of WebSphere, I found that including the and .credentials properties in that file caused WebSphere Application Server (WAS) to attempt to start up with those parameters. WAS consequently failed to start because the operating system doesn't know about that user.

    So, the complete answer, should anyone else find this thread when searching for the information I was, is:

    1. In your WebSphere Application Server install directory, create a file in JAVA_HOME/jre/lib called with a line like the one below. You will have to restart your Maximo server (MXServer).


    2. In Sonic, define queues, the Connection Factory, and the Destinations.

    3. In Maximo, define an End Point with the following properties:













    4. In Maximo, associate a Publish Channel to an External System and the End Point created in step 3.

    5. You should be away!

    I will note that I haven't tested inbound, yet. I plan to test that shortly and post back to this forum whether it works or what has to be done instead.

    Best regards,

    Jason Uppenborn

    Business Consultant

    Vetasi Limited

  • That is fine, I set the env variable prior to get the context.

    .properties files is just the simple text file, I am just wondering don't I need to get and custom varsion of properties like properties or something like to substitute the env variable when it(program) reads the properties file.

  • You can do it explicitly, by adding something to the environment, but the JVM will prepopulate the environment from the System properties file.   Typically you can set these from an administrator configurations.

    Check out java.lang.System#getEnv() or setEnv()


    public static String getenv(String name)

        Gets the value of the specified environment variable. An environment variable is a system-dependent external named value.

        If a security manager exists, its checkPermission method is called with a RuntimePermission("getenv."+name) permission. This may result in a SecurityException being thrown. If no exception is thrown the value of the variable name is returned.

        System properties and environment variables are both conceptually mappings between names and values. Both mechanisms can be used to pass user-defined information to a Java process. Environment variables have a more global effect, because they are visible to all descendants of the process which defines them, not just the immediate Java subprocess. They can have subtly different semantics, such as case insensitivity, on different operating systems. For these reasons, environment variables are more likely to have unintended side effects. It is best to use system properties where possible. Environment variables should be used when a global effect is desired, or when an external system interface requires an environment variable (such as PATH).

        On UNIX systems the alphabetic case of name is typically significant, while on Microsoft Windows systems it is typically not. For example, the expression System.getenv("FOO").equals(System.getenv("foo")) is likely to be true on Microsoft Windows.

  • Sorry for the delay..

    Inbound is a bit different. WAS doesn't allow external access to its JMS queues, so we configured Sonic to use HTTP to post messages asynchronously to our External System / Enterprise Service in Maximo. It is asynchronous because Maximo puts received messages into the appropriate JMS queue in WAS, from which point normal processing takes over. (Exposure of an HTTP Post interface is part of out of the box Maximo.)

    I hope that helps someone else.

    Best regards,

    Jason Uppenborn

    Business Consultant

    Vetasi Limited

  • Hi,

    I'm working on a customer location and we have configured Maximo as described below. But we don't see any connections being created within sonic.

    Added four jar files to the lib folder.

    - sonic_Client.jar

    - sonic_XA.jar

    - sonic-jms-api.jar

    - sonic-jndiloader.jar

    Created the file and stored it in java/jre/lib

    Is there any way to see in WAS that the connection is created, in the log files I can't find a thing.



  • This doesn't directly answer you question, but you'll also need SonicMQ's mfcontext.jar file if you're connecting to the Sonic JNDI store.  (On the other hand, you mention sonic-jndiloader.jar so maybe you're putting the SonicMQ connection info' into a non-Sonic JNDI store?)

  • Hi,

    I'm getting a message in Sonic MQ, but the message is in HEX instead of xml. Any ideas why this could be the case.


  • Hi,

    We got to work, but it seems that Maximo does not provide message guaranteed delivery when you start using another JMS provider. We lost a couple messages when the broker was not available.