Resolving Connection Issue in Seeburger Workbench Mapping Variables

Brief Description

In one of our projects, we had a couple of outbound interfaces where in, IDOC is the sender and EDI sub-system is the receiver.  The message mapping was completed and we did rigorous testing in development and the interface worked successfully. The IDOC was triggered and the EDI file was getting generated without any issues.

In the ISA segment, there is a field D_I12 is the Interchange control number.  This is the way that an EDI sub-system identifies the envelope.  This control number should not be random, but it should be an incrementing number and it should be 9 digits padded with zeroes.

The below UDF along with a combination of more UDFs maintains a counter in the Seeburger workbench and increment’s it each and every time whenever this interface is executed and returns the counter value back to the mapping and to the output EDI file. This was all working perfectly fine when we tested in our Development environment.  Later we decided to move the interface to Quality and conduct further testing on the interface before moving it to Production.

When the IDOC was triggered in Quality system, the outbound interface failed at mapping level.

Below is a screenshot of the Seeburger Workbench where the counter variables are maintained and are incremented on every execution.

Error

Usually, this UDF would establish a connection to the Seeburger Workbench and increment the mapping variable and return the increamented value. After debugging in the Quality,we found the source of the error. 

The UDF could not establish a connection to the Seeburger Workbench. This was the root cause of the error. Why a connection could not be established, it required deeper investigtion

Investigation

There are java classes which are provided by Seeburger, This is usually found in your Seeburger software component, under “imported archives” I found the java classes which were used for the connection purpose.  After identifying the “properties file” which contained values for various parameters like host, port etc i found it pretty strange that the Port, “50000” was hardcoded and it was not dynamic, but I am sure there must be a reason why this was done. I immediately checked the port of my Quality server and it was a different port, it was not 50000. hence it did not match the port that was hardcoded in the properties file. There were 2 properties file which contained the hardcoded port.

1)    1)  com.seeburger.functions.permstore.CounterFactory.properties

2)   com.seeburger.functions.permstore.VariableFactory.properties  

Solution

The port in these 2 files had to be changed to match my Port in my Quality system. I exported the java class from the Imported Archives and opened the file in a notepad, changed the port number to my port and saved the file. The files were then imported back again and i activated the imported archives which contained the change in the properties files. I re-triggered an IDOC and this time there was no error and the UDF was able to make a successful connection to the Seeburger workbench and return the incremented counter value.

Similarly we applied the same solution too in production environment and corrected the same issue.

I hope this solution will help you in case your ports are different for each environment.