IBM Support

Troubleshooting issues with the SAP Suite Adapter for JCo 3.x in a Unix/Linux environment

Technical Blog Post


Abstract

Troubleshooting issues with the SAP Suite Adapter for JCo 3.x in a Unix/Linux environment

Body

I recently worked with a customer who had successfully installed a fix pack to Sterling B2B Integrator only to find that the SAP Suite Adapter for JCo 3.x would longer start.

I checked all the usual suspects:

  1. <SI Root>/install/properties/dynamicclasspath.cfg contained a reference to the sapjco3.jar.
  2. The <SI Root>/install/jar/sapjco3/<sap version> directory contained the sapjco3.jar
  3. <SI Root>/install/sapjco3/<sap version>/linux directory contained the library file.

Everything looked fine, so  we used a time-honored technique to determine whether SI could find the sapjco3.jar and its library:

In the SI User Interface, we went to Deployment > Utilities > SAP Suite Builder 3 > IDOC Meta Data Builder and clicked Go.

If you try this and you are prompted for credentials, that tells you that SI can find the sapjco3.jar and its library.  In this case, we saw an error message, which told us what we already suspected - the sapjco3.jar and libsapjco3.so were in place, but for whatever reason, SI could not find them.

As a rule, installing a patch will not clobber SI's ability to find the SAP components, but in this case, something clearly had.  The quickest course of action seemed to be uninstalling and reinstalling the sapjco3.jar and library.  We set to work.

The first order of business was to stop Sterling B2B Integrator by executing .hardstop.sh in the <SI Root>/install/bin directory.

The second step was to copy the sapjco3.jar and the libsapjco3.so out of the SI directory structure and into another directory for safe keeping (you can skip this step if you already have back up copies of these files.)

The third item on the agenda was to execute  ./install3rdParty.sh -list from the <SI Root>/install/bin directory This returned (in part):

 ./install3rdParty.sh sapjco3 -list
** Looking /opt/si/install/properties/dynamicclasspath.cfg.in file ...
**** Found a match &INSTALL_DIR;/jar/sapjco/3_0_10/sapjco3.jar
** Looking /opt/si/install/properties/OPSDynamicclasspath.cfg.in file ...
**** No match found
** Looking /opt/si/install/properties/APPDynamicclasspath.cfg.in file ...
**** No match found
** Looking /opt/si/install/properties/AGENTDynamicclasspath.cfg.in file ...
**** No match found
** Looking /opt/si/install/properties/ACTIVEMQDynamicclasspath.cfg.in file ...
**** No match found
** Looking /opt/si/install/properties/ACDynamicclasspath.cfg.in file ...
**** No match found
[TIMING] - InteropBuildHelper completed: 0 seconds.

It was now time to uninstall the sapjco3.jar:

./install3rdParty.sh sapjco 3_0_10 -j /opt/si/install/jar/sapjco/3_0_10/sapjco3.jar -uninstall

I wasn't sure if I needed to do the same for the library file, so what the heck, I  executed the command again on the library:

./install3rdParty.sh sapjco 3_0_10 -l /opt/si/install/lib/sapjco/3_0_10/linux/libsapjco3.so -uninstall  (Note: the -l that you see is a lower case L.)

So far so good.  Running these commands does not delete the files themselves, so for good measure, we executed two more commands:

rm -rf /opt/si/install/jar/sapjco

rm -rf /opt/si/install/lib/sapjco

Time now for a public service announcement:  Always have a backup of SI and the database before you execute commands that delete files - that way, you can restore if anything goes wrong!  Too,

exercise extreme caution with commands such as rm -rf.  Be careful and you won't inadvertently delete a file that you hadn't intended to delete!

With the uninstallation accomplished, it was time to reinstall:

In <SI Root>/install/bin, we executed:

./install3rdParty.sh sapjco 3_0_10 -j <path to the backed-up sapjco3.jar>/sapjco3.jar

then:

./install3rdParty.sh sapjco 3_0_10 -l <path to the backed-up libsapjco3.so >/libsapjco3.so  (Note:  the -l is a lower case L)

We decided to throw caution to the wind - we didn't check the dynamicclasspath.cfg or the SI directory structure.  We simply started SI.

After the restart, the SAP Suite Adapter for JCo 3.x started up without difficulty.

These steps aren't usually necessary, but if you find that SI cannot find the sapjco3.jar and/or its library, these steps can restore the SAP Suite Adapter for JCo 3.x back to functioning properly.

[{"Business Unit":{"code":"BU012","label":"WCE"}, "Product":{"code":"SSMHNK","label":"IBM Sterling B2B Integrator"},"Component":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"","Edition":""}]

UID

ibm11120503