Transport handling errors have burned nearly everyone involved in SAP change at some point in time, and may have even caused a production outage. Across industry, the stories are surprisingly consistent: having tested every aspect of the new release, and with confidence of success, cutover is staged. The transports import into production and the worst happens. Diagnosis reveals the problem was transport-related, not functional: the transports were imported in the wrong order, or one missed the import bill, or one back-versioned an object, introducing a regression. Sound familiar?
In theory, testing should find these problems, right? Unfortunately, functional testing performs poorly finding this type of defect; it’s the wrong tool for the job. So, why do we use functional testing in an attempt to prevent these types of problems?
Generalizing, SAP teams use functional testing to identify two distinct types of defects: A functional defect arising from a programming or logical error in the code; or a technical release defect, often the result of a transport handling issue. With functional defects, the wrong behavior or outcome is produced, and the appropriate way to detect these is functional testing. A technical release defect often results from a transport handling error and the architecture of SAP itself. These include common mistakes such as incorrect import ordering, overtakes, overwrites, and missing transports, as well as dozens of others all related to the handling of individual transports in the release plan.
If functional testing and manual tracking worked well for identifying technical release defects and transport handling problems in SAP, firms could detect issues and prevent them. No release manager would have the enviable job (cough, cough) of tracking spreadsheets of transports and objects to try and prevent them. However, technical release defects remain common in SAP environments, and often compose a large proportion of outage events. Neither testing or manual tracking works as perfectly as it should, and both approaches are time consuming and inherently non-value-add activity: After all, the best outcome is nothing is found or happens, and all we’ve done is waste time looking.
One can learn a lesson here from outside SAP: the DevOps concept of Continuous Integration. In languages such as C# or Java, the build-and-deploy process is seasoned with automation, tracking code in a version control system, building new executables with scripted, consistent processes, automatically testing code changes for conformance with technical contracts, and so on. The possibilities of a good Continuous Integration / Continuous Delivery pipeline are well beyond this article, but it is possible to do these same kinds of things in SAP. And, we should.
The focus of Continuous Integration in SAP is automating transport handling and change control. At a basic level, automation should include the detection of overtakes, overwrites, back versioning, required manual (non-transportable) changes, import ordering, dependencies (missing transports and objects), checking for sensitive object changes and perhaps others depending on the environment. A more sophisticated Continuous Integration approach would automate retrofit and conflict detection in N+1/n environments, integrate Code Inspector and ABAP Unit test, and automate the creation, release, and tracking of Transports of Copies.
One telling indicator of how well this works is our backout functionality: We developed a transport backout technology years ago in response to customer demand for a solution to address transport handling accidents, reducing resulting downtime. Often, customers licensing our ActiveControl technology consider this feature heavily when evaluating the business impact of investment in our technology. But most of our customers report the capability is rarely used. Why? Because implementing good Continuous Integration practices, in-line analysis and early detection of transport handling issues eliminates the need for such a safety button.
What impact would eliminating technical release defects, and the use of functional testing to detect them, provide for your organization? Would it prevent a severe outage (or two!) annually? Would having consistent confidence in release quality allow you to support the business better, with more frequent change deliveries and better reliability? Would it free up a release manager, who’s tracking this manually, to do more valuable activity? What would the economic and competitive advantages of these changes be worth to your enterprise?
If eliminating the need to test for ordinary transport handling issues, reducing outages and mistakes, and adopting DevOps methodologies and automation in your SAP environment sound appealing, I would encourage you to investigate ActiveControl from Basis Technologies. ActiveControl is designed specifically for SAP, solving these challenges for ECC, S/4HANA and many SAP application technologies.
