Starting line

Our customer, a global giant in its field was gradually increasing in size. With this shift, more employees and systems managing them started to be required. These systems, internal or external, needed a steady flow of HR data. A new challenge, what kind of integration will be needed for these systems? The data needed for exposure were managed by the central SAP system. This system was also our source of trust which was holding the majority of the business process logic. In this topic, we are focusing on the challenges in the development process we faced when integrating the human resource data with external partners. Mainly the exposure of sensitive information protected by GDPR.

• Tracking of travel expenses
• Parking
• Real estate
• Attendance management
• Employee security services
• Travel agencies

Pilot

The first project covered the travel expenses. External partner provided an application that was able to track travel expenses of the employees and return them to the employer. The main goal was to integrate this external application with an internal SAP system.

Integration pattern we chose

1. Retrieve XML files generated by the application via SFTP on a scheduled basis
2. Push the file content into the webMethods integration server
3. Map the content into the “neutral” canonical format
4. Push the data into SAP Functional module
5. Send email notifications to business

Defining a new pattern

Our second challenge came in the form of attendance management. External partner provided an attendance management system for the company employees. The application needed a stable and scheduled data feed from the internal SAP system. This meant that the direction would be opposite to our first case, our team would be responsible for extraction and creation of the flat files. The request was to create a scheduled interface that would extract a list of employees and their attendance from the central SAP system and send this data to the external party responsible for the management. Now, we couldn’t simply extract everything and expose whatever data was available in the SAP function module. Three main groups of data availability were specified: confidential, internal, and external. It was decided based on these flags which data to send to which system.

Integration pattern we chose

1. Create a scheduled service which calls SAP functional module based on the input
2. Retrieve the data into the webMethods integration server
3. Map the content into the “neutral” canonical format
4. Limit the amount of data in the mapping based on the confidentiality level
5. Create a flat file
6. Push the flat file to the partner via SFTP/SMB protocols
7. Send email notifications to business

Paved way for future requests

This new integration pattern proved itself tremendously reusable in the future. We received dozens of requests which needed integration with external partners, where we had to limit the data partner is receiving. Additionally, the customer requested functionality to call this data at-hog for testing purposes. This meant that we had to design an API that would return the data immediately after the call was made. The pattern in the near future will probably have the part which chooses the level of data exposed moved into the API gateway. This way the solution will gain additional security and accessibility to the users. Steps such as level of data exposure will no longer be middlewares role, it will be able to focus on its primary function - data integration, and leave the business logic to the other applications.

Integration pattern we chose

1. Create a scheduled service which calls SAP functional module based on the input
2. Retrieve the data into the webMethods integration server
3. Map the content 1:1 (business logic is handled by the API gateway)
4. Create a flat file
5. Push the flat file to the partner via SFTP/SMB protocols
6. Send email notifications to business

Benefits

11 new partners integrated

Reusable pattern

Added security

What did we learn from these projects? Always think in terms of longevity and reusability. Never design solutions without a clear vision for the future, otherwise once the number of projects which need to be supported increases, your platform will become an unsupportable mess.

- Someone very smart, Maestro of IGTC