Gentran for iSeries SAP Extension

The SAP Extension for Gentran iSeries will work with a non-iSeries instance of Gentran, although Sterling's documentation doesn't explain how to set it up for this scenario. Considering SAP created the RFC capability specifically so that R/3 may call or be called regardless of where it's sitting. Hence, it works fine with a little ingenuity.

R/3 to Gentran

The call from R/3->Gentran is the most complex; essentially, you have to run RFCEXEC as a persistent job in register mode. Hence, it starts up and registers itself with R/3 and waits for calls. The R/3 system will need authorization to the IFS.

Call ADDENVVAR ENVVAR(RFC_INI) VALUE('/QSYS.LIB/R346DRFC.LIB/INI.FILE/SAPRFC.MBR') before calling RFCEXEC in your persistent job.

In R/3, you setup the SM59 RFC destination to point to this registered service. Once it's running you can test connectivity.

In your WE21 file port defintion, you'll need to indicate that an automatic start is possible, specify the RFC destination you created above, and then specify the name of your CL in your outbound trigger definition. I.e.,
  1. Directory: /qsys.lib/g3x3pgm.lib/
  2. Command File: SAPOUT.PGM

In your WE20 partner setup, point the partner to the WE21 file port you created above.

Gentran to R/3

Inbound isn't as difficult. The call to R/3 will basically work the way you expect as long as you provide the right parameters. We had to use the phyiscal app server name for our application server; the instructions in the manual gave us an incorrect name.

Using a file share instead of the IFS

If you want to exchange files via a file share rather than through the iSeries IFS, then it gets more complicated.

On the Gentran->R/3 call, you'll need to create your own STARTRFC CL that intercepts SAPIN's call to SAP's STARTRFC. This CL would use iSeries' QNTC commands to copy the file to the file share and then update the STARTRFC parms to point to this share prior to submitting (not calling -- that doesn't work) the real STARTRFC.

On the R/3->Gentran call, you'll need another CL that's called by your port trigger (rather than SAPOUT). This CL will move the outbound file from the share to the IFS, and then call SAPOUT using the IFS file name as the parameter.

So, it is possible and it seems to work pretty well as long as you plan well enough to keep jobs from stepping on each other and/or you use work management to run Gentran in a single-threaded queue.