Leveraging SAP Transport Automation with IT-Conductor

Authored by Danica Esteban
  

This case study talks about the basics of SAP Transport Management and how IT-Conductor SAP Transport Automation can help transform your implementation projects like it did for a Fortune 100 medical device company.

To say that managing transport requests is challenging would be an understatement. It involves several possible risks if not managed properly. In large SAP implementation projects that process hundreds or thousands of transport requests, some misses in production will most likely occur. When that happens, incorrect object versions can, later on, cause a defect in the production environment, not to mention inherent delays and associated costs. This is why it’s important that transport management systems are in place to properly manage, control, and import development objects from one SAP system to another.

In the quarterly feature we published last year, we briefly talked about how we simplified the process of moving transport requests in SAP. It was a big leap in our automation efforts as we collaborated with a Fortune 100 medical device company to develop a solution that removes this pain point of having to process transport requests manually. After a year of using the IT-Conductor SAP Transport Automation, we received tremendous feedback about how they were able to immensely reduce their development and testing efforts in their implementation projects and how they were able to save time drastically.


Table of Contents

SBX vs. DEV vs. QAS vs. PROD in SAP Systems

What are Transport Requests?

Customizing Transports vs Workbench Transports

    Customizing Transports

    Workbench Transports

Traditional Way of Managing Transport Requests

Conceptualization: Automation of Transports to QA and Sandbox Systems

SAP Transport Automation in Action

    SAP Change Request Web Form

    Change Request Processing Composer

    Dashboard

Why You Should Automate Transport Requests

    1. Reduce Processing Time

    2. Reduce Manual Processing

    3. Reduce Risks

    4. Compliance

    5. Reduce Complexity


SBX vs. DEV vs. QAS vs. PROD in SAP Systems

Before we dig deeper into this automation feature in IT-Conductor, let’s quickly discuss the concepts behind the three different environments in SAP systems, namely Sandbox, Development, Quality, and Production. 

  • Sandbox or SBX system in SAP is optional but often recommended as an agile exploration playground for creating a proof-of-concept feature.
  • Development or DEV system in SAP is where a developer develops programs and/or applications. DEV environments usually do not contain business or transactional data.
  • Quality Assurance System or QAS in SAP is usually where a developer or test engineer tests the program or application developed in the DEV system.
  • Production system in SAP is the environment where the program or application is running and it is where live business transactions take place.

In most cases, especially in large enterprise environments, DEV and QAS are separate systems. In some smaller environments, however, DEV and QAS act like one. Regardless of your business's situation, transport requests are utilized before deploying or importing code and configuration changes in production.

What are Transport Requests?

A transport request is a package that transfers code and configuration changes from one SAP system to another. It is commonly initiated by the developer or the test engineer. Think of it as a container that carries information regarding who initiated the request, the source and target system, the type of change, the purpose of the transport, and, most importantly, the configuration changes.

Whenever developers complete their development work, they need a place to test it, either in the same environment where the development was carried out or in another system like the QAS. Once the development has been tested and the end users are satisfied, they can move it down to the production system to be used by the end users.

Customizing Transports vs Workbench Transports

There are two types of transport requests that we have employed in this automation project the customizing transports and the workbench transports.

customizing and workbench transports

Figure 1: Customizing  and Workbench Requests

Customizing Transports

Customizing transport requests involves changes that only affect a particular client. If you change the client-specific data, the system will prompt you to store and import those changes to the target system.  

Workbench Transports

Workbench transport requests, on the other hand, involve changes that span across clients. If you change client-independent or cross-client data, the changes will automatically be reflected in all the other clients.

Traditional Way of Managing Transport Requests

Managing transport requests is executed manually where the developer initiates transport requests, performs adjustments in queues, runs the export task, and the SAP Basis team (or Transport administrator) schedules it in the queue for later import when approved. On top of those activities, approvals are also in place to govern the change management procedure. All those activities, plus the fact that administrators and stakeholders also need to be notified once the transport requests have been imported successfully or if they failed and need remediation before a re-transport. Overall, it takes so much time and effort due to a lack of workflow automation.

This sparked the conversation with the medical device company about the automation of transports.

Conceptualization: Automation of Transports to QA and Sandbox Systems

It all started with an inquiry to check if automating the transport process to QA and sandbox systems was feasible. Given that they don’t want anything released from the DEV systems to be directly imported to the QA and sandbox systems, they wanted to give the developers the option to initiate transport requests via e-mail. With the capability of the IT-Conductor to read e-mails, developing a parsing algorithm to read information from e-mails is possible.

While parsing information from change request e-mails, their SAP Basis team and our automation experts encountered some roadblocks, realizing that using e-mail as a triggering mechanism for process automation is unreliable. So, our automation experts suggested exploring another option to use the IT-Conductor Process Automation engine using API calls when submitting change requests. For this, they worked with their Unix administrator and set up a dedicated web server to capture the change request information over a web form from the internally hosted website. At the same time, our automation experts helped design and build the web form to capture the change request information, giving them a way to initiate transport requests using IT-Conductor and manage the end-to-end process of transport request change management.

SAP Transport Automation in Action

With IT-Conductor’s capability to orchestrate complex IT operations, we were able to design and develop an automated solution to manage transport requests. Since IT-Conductor already monitored this medical device company's different SAP systems, developing an end-to-end workflow was less intricate than implementing a solution that needed to be integrated with their existing systems.

We have already worked on different automation solutions using IT-Conductor, and SAP Transport Automation is one of them. To quickly understand how it works on a high level, we have divided the following sections into three parts – the implementation of the SAP Change Request webform, the Process Change Request Processing Composer, and the Dashboard that shows the status of the transport requests.

 

 

SAP Change Request Web Form

The process starts with the developer initiating a transport request using the SAP Change Request Web Form. This is where all the required information is captured.

SAP Change Request Webform

Figure 2: SAP Change Request Web Form

In the form above, you can see that the developer or the requestor can select the Source SID, define the Target SIDs, and indicate the requestor’s SAP User ID. Take note that the capture takes place on the gateway. Once the requestor submits the transport request, it will send a request to IT-Conductor to create objects to capture the transport request(s) submitted. It is also important to note that upon submission of the form, the requestor’s SAP User ID will be used to pull the user’s e-mail address through an RFC call and stored in SAP.

Change Request Processing Composer

In the process defined below, you can see that the user details collected upon the submission of the form will trigger an e-mail with the transport request information to be sent to the requestor and other stakeholders (e.g., SAP Basis Distribution List). This is to ensure that all the concerned parties are aware of the request(s) for changes in the system.

change request processing

Figure 3: Transport Request Process 

Apart from the user details, the API call upon form submission will allow IT-Conductor to extract the source SAP System IDs and the table of all the transports (customizing or workbench). This list of transports will then be passed to an SAP Function module to verify if all the transports are in a “Released” status. The entire transport submission process will be rejected if any have a “Not Released” status.

Should all the transports pass the verification step, the process will continue to extract information about the target SAP System IDs. The tool will process the requests from this table according to their type. For customizing transports, the requests need to be imported in sequence. For workbench transports, the requests can go together with the dependencies check.

After the transports are imported, IT-Conductor will send an e-mail notification with the transport import status to the requestor and other stakeholders defined in the process definition.

Dashboard

All submitted transport requests will show up in the dashboard, allowing the SAP Basis teams to monitor the status of the requests submitted by the developers.

SAP Change Management Dashboard

Figure 4: SAP Change Management

In the image above, you can see whether the transport request succeeded or failed. You can also see the number of requests per source system, the number of transport requests that have been transported, and the number of requests raised per user in the last 24 hours.

Why You Should Automate Transport Request Management

Transport requests are crucial, especially when moving changes from DEV to QAS or from DEV/QAS to PROD. Given the complexities involved from the moment the transport is released to importing the changes to the target system, having an automated solution will definitely:

1. Reduce Processing Time

Since transport requests may be submitted in bulk using this automation feature in IT-Conductor, combining requests into a single sequence and importing them will save you processing time.

2. Reduce Manual Processing

Without automation, processing transport requests involves defining the configurations for the domain controller, determining the transport route, logging in to the systems to execute commands manually, and so on. Having an automated solution in place will help your organization reduce manual processing.

3. Reduce Risks

Ultimately, the risk of importing incorrect object versions in production will be greatly reduced since manual processing will be eliminated, and all behind-the-scenes processing and verification will be handled by the solution.

The sequence to which transport requests are processed is also crucial when moving a request from DEV to QAS or DEV/QAS to PROD. With how IT-Conductor is designed to oversee and relate all components in your environment, the transports will seamlessly find their way from whichever source system you define in the request to the target systems, all ensuring that their respective sequences correspond to the objects created upon submission. Imagine having to manage several development projects in your environment manually. Even with a change management process, you will never fully control what goes to production with your knowledge.

4. Compliance

Most large and/or public companies need change audits in their environment to ensure compliance related to specific industry regulations. IT-Conductor fully logs and reports on the end-to-end process of transporting changes throughout the SAP landscapes, providing audit trails related to what, when, where, who, and how transports are managed. 

5. Reduce Complexity

SAP customers often wonder how to achieve similar automation with SAP Solution Manager's ChaRM (Change and Release Management). ChaRM requires a full implementation, system dependence on the Solution Manager, and constant lifecycle management with SAP updates. IT-Conductor provides a simple yet elegant orchestration solution to allow developers, change managers, Basis administrators, and compliance auditors easy access to request, transport, monitor, and report on SAP changes.