connecting to Sonic ESB 7.6 from Maximo 7.1 or WebSphere 6.1

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

like

          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.connectTimeout=120000
          com.sonicsw.jndi.mfcontext.tryBackupOnFailure=true
          com.naming.security.principal=user
          com.naming.security.credentials=pass
          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

http://www.vetasi.com

+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

com.sonicsw.jndi.mfcontext.domain=$variable.

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
com.sonicsw.jndi.mfcontext.domain=$variable.
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 jndi.properties file in JAVA_HOME/jre/lib with that property in it. In the case of WebSphere, I found that including the java.naming.security.principal 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 jndi.properties with a line like the one below. You will have to restart your Maximo server (MXServer).

com.sonicsw.jndi.mfcontext.domain=YourDomain

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

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

Handler=JMS

CONFACTORYJNDINAME=YourSonicConnectionFactory

CONTEXTFACTORY=com.sonicsw.jndi.mfcontext.MFContextFactory

DESTINATIONTYPE=javax.jms.Queue

DESTJNDINAME=YourSonicInOrOutDest

ISCOMPRESS=0

JMSEXIT=

PASSWORD=yourPassw0rd!

PROVIDERPASSWORD=

PROVIDERURL=tcp://YourSonicBrokerHost:2506

PROVIDERUSER=

USERNAME=YourSonicUsername

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

http://www.vetasi.com

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()

java.lang.System

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

http://www.vetasi.com

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 jndi.properties 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.

Yours,

Martijn

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.

Martijn

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.

Martijn

Can you enable FT on the Sonic ConnectionFactory in the JNDI store?