I run into this requirement all the time at clients. My current client is implementing SAP and the development team has decided to build file based interfaces. In this particular case we are implementing interfaces between SAP and JD Edwards.

The basic requirement is as follows: SAP needs to be able to write files that JDE can read/delete and visa-versa JDE needs to write files that SAP can read/delete. Both servers are running UNIX.

High level outline of process:

1. Define Example Landscape
2. Create An Integration File System
3. Export File System and Mount
4. Example Issues / Scenarios
5. Creating A New UNIX Group
6. Set Integration Directory Group Ownership and Permissions
7. Adjusting The Umask

Define Examples SAP and JD Edwards Landscape

So let’s create an example landscape. In our example, we have an SAP development system with the SID DEV–we will call this system SAPDEV. We also have a JDE development system that we will call JDEDEV. In this example, we will only discuss the steps to integrate the two development servers. You will need to repeat this process and/or modify this process to configure the rest of your landscape. Please note DO NOT ever mount production systems to QA and DEV systems.

Creating An Integration File System

So, the first step in this process is to create seperate physical file system for your interfaces to use. This file system is to be separate from the OS, SAP kernel, and SAP database. This is a very important step of the process. I have been working with SAP customers for many years and I am always amazed that this step is often skipped. It is important that you create a seperate file system because it is to easy to accidently fill up your file system with interface files. You certainly don’t want your interface files sharing the same file system as the OS, SAP Kernal, or SAP DB. Usually when these componets of the server run out of space bad things happen.

Next you may be wondering how big a file system is required, that answer certainly depends on a lot of project specific variables. In general, a 10 gig file system should be a good starting point for most SAP projects. However, an in-depth analysis is required to determine an appropriate amount of storage.

Export File System and Mount

In our example, we have created a 10 gigabyte file system for the interfaces and have mounted it to the root of the SAPDEV server as the folder /transfer. We have exported this folder from the SAPDEV host and created an NFS mount to the root of the JDEDEV server as the folder /transfer. Our servers now have a shared file system between them.

In AIX you can check your file systems by using the following command:

df -g

Or by reviewing the the filesystems file by using the following command:

more /etc/filesystems

Example Issues / Scenarios

So far in our example this has been a pretty straight forward exercise. Now comes the tricky part; making it so each server has the correct permissions to read and write to the files. Let’s also assume for this example that we are going to open this directory up completely from a permissions perspective.

From the root directory issue the following UNIX command to check the /transfer folders permissions.

ls -l | grep transfer

drwxrwxrwx devadm sapsys 1000 Aug 28 2008   transfer

If your permissions are different from the root director as user <sid>adm, issue the following command:

chmod 777 transfer

This will completely open up the permission on this directory.

In this example the directory was created by the SAP sidadm account (devadm). The sidadm account has a primary group of sapsys. The permissions on this directory are set to allow any user in any group to read, write, and execute from this directory.

When an ABAP program is developed to write a file, it will always write the file with the <sid>adm account (devadm in our example). When a file is written, it will use the default umask for the user to set the file’s permissions. If we were to write an interface file to /transfer it would look something like this in UNIX.

(SAPDEV) /transfer

-rw-r--r--  devadm  sapsys  256  Aug 28 2009  sap_interface_file.txt

Let’s quickly jump over the fence and look at JD Edwards. When a JDE program is developed to write a file, it will always write the file with the JDEXE account. Like SAP, when the file is written it will use the default umask for the user to set the file’s permissions. If we where to write an interface file to /transfer on JDE it would look something like this in UNIX.

(JDEDEV)/transfer

-rw-r--r--  jdexe  jdexe  256  Aug 28 2009  jde_interface_file.txt
-rw-r--r--  devadm  sapsys  256  Aug 28 2009  sap_interface_file.txt

We now have two files in the directory. If you where to list the contents of the directory on either server you will see the two files.

ls -l

/transfer
-rw-r--r--  jdexe  jdexe  256  Aug 28 2009  jde_interface_file.txt
-rw-r--r--  devadm  sapsys  256  Aug 28 2009  sap_interface_file.txt

Simply mounting a file system between the two boxes is not enough to share files. Neither devadm or jdexe can update, move, or delete the file written by the other server. Specifically, sap_interface_file.txt has -rw-r–r– for its permissions JDEXE can open and read this file but can not change it. Most SAP integration scenarios that are file based read the file and then archive/delete it. The same issue is true for jde_interface_file.txt <sid>adm can open and read this file but can not change it.

The Easy Out – Scenario

One simple solution would be to add jdexe to the sapsys group and devadm to the jdexe group. However, this is not a good option from a security perspective. This would give the JDE admin authorization to SAP and SAP admin authorization to JDE.

More Secure – Scenario

Create a new UNIX group on both servers to own the /transfer folder, add both <sid>adm and JDEXE as secondary group members, adjust the users Umasks, and set the GID bit on the folder.

Let’s Create A New UNIX Group

In our example lets call the group “transfer”. We need to add both <sid>adm and jdexe added to this group as a secondary group; althouh they both keep their primary groups, sapsys and jdexe respectively.

To see what groups are configured on your server issue the following UNIX command:

more /etc/group

...
owner:*:10:
everyone:*:12:
group:*:16:
staff:*:20:root
sapsys:*:200:adm
...

The group file contains all the groups configured for a server. In my example, I am going to assume that there is no central user configuration on your UNIX servers. Therefore, when this group is created on both the SAP and JDE server it is important that it is created with the same Group ID. It is important that you pick a Group ID that is not used on either server. On AIX you would use the SMITTY utility to create the group. For this example we will use the group ID 300.

To see the new transfer group created in SMITTY you can check the /etc/group file.

more /etc/group

...
owner:*:10:
everyone:*:12:
group:*:16:
staff:*:20:root
sapsys:*:200:adm
...
transfer:*:300:

Set The Integration Directories Group Ownership and Permissions

Next, we need to change the ownership on the /transfer folder to have the owner group be “transfer” and not “sapsys”.

ls -l | grep transfer

drwxrwxrwx devadm sapsys 1000 Aug 28 2008   transfer

To change the ownership we run the UNIX command:

chown :transfer /transfer

Let’s check our work:

ls -l | grep transfer

drwxrwxrwx devadm transfer 1000 Aug 28 2008   transfer

Notice the group is now “transfer”, not “sapsys”.

Next, we need to change the permissions on the /transfer folder to something a bit more secure, as well as set the GID bit. From UNIX issue the following command:

chmod 2770 /transfer

Let’s check our work:

ls -l | grep transfer

drwxrws--- devadm transfer 1000 Aug 28 2008   transfer

Notice the “s”; that is the GID bit. Setting this bit will force all files to adopt the group ownership of the parent directory not the primary group of the user. We are almost there. Let’s write another file from SAP and JDE and check that file’ permissions. From UNIX issue the following command after writting a file from SAP and JDE to the /transfer directory.

ls -ltr

/transfer
-rw-r--r--  jdexe  jdexe  256  Aug 28 2009 00:00  jde_interface_file.txt
-rw-r--r--  devadm  sapsys  256  Aug 28 2009  00:00 sap_interface_file.txt
-rw-r--r--  devadm  transfer  256  Aug 28 2009  00:00 sap_interface_file._2.txt
-rw-r--r--  jdexe  transfer  256  Aug 28 2009 00:00  jde_interface_file_2.txt

Notice the group on both files is now “transfer”. However, we have still not fixed our problem because both files were created with 644 permissions. We need our permissions to be 664 for every file written to this directory. We will, therefore, need to adjust the UMASK for <sid>adm and jdexe.

Adjusting The UMASK

To determine the UMASK to use, you must take the permission you want and subtract it from 777 to get your mask. In our case we would like the files to have 664 permissions.

777 – 664 = 113

You will need to set the UMASK to 113 for both <sid>adm and jdexe.

Let’s run one more set of tests. Let’s write another file from SAP and JDE and check those files out. From UNIX, issue the following command after writting a file from SAP and JDE to the /transfer directory.

ls -ltr

/transfer
-rw-r--r--  jdexe  jdexe  256  Aug 28 2009 00:00  jde_interface_file.txt
-rw-r--r--  devadm  sapsys  256  Aug 28 2009  00:00 sap_interface_file.txt
-rw-r--r--  devadm  transfer  256  Aug 28 2009  00:00 sap_interface_file._2.txt
-rw-r--r--  jdexe  transfer  256  Aug 28 2009 00:00  jde_interface_file_2.txt
-rw-rw-r--  devadm  transfer  256  Aug 28 2009  00:00 sap_interface_file._3.txt
-rw-rw-r--  jdexe  transfer  256  Aug 28 2009 00:00  jde_interface_file_3.txt

Notice the 3rd set of files have both read and write privleges on the group. This means that both of these files can be read and changed by both user ID’s because they are both part of the transfer group.