This case study talks about the basics of SAP Transport Management and how IT-Conductor SAP Transport Automation can help transform your implementation projects just like what 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 that 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 come up with a solution that removes this pain point of having to manually process transport requests. 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 drastically save time.
"This tool has drastically improved the time it takes to get changes tested by the off-shore team."
— Sr. IT Manager, SAP Development
"Thanks to IT-Conductor for working with me in architecting and building the SAP Transport Automation solution and supporting it over the year. This self-service/automated process has immensely helped us in reducing the development and testing efforts in our implementation projects."
—Sr. SAP Basis Lead
Table of Contents
SBX vs. DEV vs. QAS vs. PROD in SAP Systems
Customizing Transports vs Workbench Transports
Traditional Way of Managing Transport Requests
Conceptualization: Automation of Transports to QA and Sandbox Systems
SAP Transport Automation in Action
Change Request Processing Composer
Why You Should Automate Transport Requests
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.
-
- The sandbox or SBX system in SAP is optional but often recommended to have as an agile exploration playground for creating a proof-of-concept feature.
- The 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.
- The quality system or QAS in SAP is usually where a developer or a test engineer tests the program or application developed in the DEV system.
- The 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, DEV and QAS are acting like one. Regardless of what situation your business is in, transport requests are being utilized prior to deploying or importing code and configuration changes in production.
What are Transport Requests?
A transport request is a package that is used to transfer 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 (this is not ideal but in some cases, DEV and QAS are acting as one) or move to 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.
Figure 1: Customizing and Workbench Requests
Customizing Transports
Customizing transport requests involves changes that only affect a particular client. This means that if you make changes to 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. This means that if you make changes to 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 as a way 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 prior to a re-transport. Overall, it takes so much time, and effort, and lost time due to a lack of workflow automation.
This is what 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 it was feasible to automate the transport process to QA and sandbox systems. Given the scenario 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 in designing and building the webform to be used for capturing 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. Having the different SAP systems of this medical device company already monitored by IT-Conductor, developing an end-to-end workflow was less intricate than implementing a solution that is yet 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.
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 will be 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.
Figure 3: Transport Request Process
Apart from the user details, the API call upon form submission will also allow IT-Conductor to extract the source SAP System IDs as well as 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. If there’s any that has a “Not Released” status, the entire transport submission process will be rejected.
Should all the transports pass the verification step, the process will continue to extract information about the target SAP System IDs. From this table, the tool will then process the requests 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.
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 Requests
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 a great amount of processing time.
2. Reduce Manual Processing
Without automation, processing transport requests involves having to define the configurations for the domain controller, determining the transport route, having to log in to the systems to manually execute commands, 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 manually manage several development projects in your environment, even with a change management process in place, 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.
Start the conversation within your organization now.
If you want to learn more, feel free to schedule a demo with us and our team will get in touch with you.
