At its heart, the SAP transport management system (TMS) is very simple: changes in a development system are packaged into files (a transport) and exported to a filesystem: the famous /usr/sap/trans. This filesystem is mounted across all of the systems in the transport path, so that when you want to import those changes into, say, your QA system, the QA system can read the transport files directly from /usr/sap/trans and update QA.
There is also the concept of a TMS Domain Controller, a central system (usually the development system) which can act as a central point of control and coordination for transports across the landscape. The TMS Domain Controller needs to be able to communicate (via SAP RFC) with all other systems in the landscape.
This set-up, with a single TMS Domain Controller and the same /usr/sap/trans being mounted across all systems in the landscape, is the standard SAP configuration and works brilliantly for the vast majority of SAP customers.
Unique Industry-Specific Challenges
However, there are situations where this is not possible. We see this particularly in certain highly-regulated industries (e.g., pharmaceuticals, finance) or in industries or customers with extremely stringent security requirements (aerospace and defense, for example).
These customers often need to segregate their production systems from their non-production estate, with no shared infrastructure between the low-security and high-security sides (we’ll call these the low side and the high side). This means that production will have a separate /usr/sap/trans filesystem to the rest of the landscape. Now this, in itself, is not a problem for the TMS, which has the concept of transport groups to allow for the transfer of transport files between different /usr/sap/trans filesystems. However, in addition to having no shared infrastructure, it’s often the case that in these high-security environments there can be no direct network connectivity between the high side and the low side, and this can greatly complicate the way that transport management works.
This set-up is often known as an air gap – there is a complete physical and logical split between the two sides.
Two Types of Air Gaps:
- A bridged air gap
In this configuration, there is a DMZ between the high and low sides. Whilst the high and low sides can’t talk directly to each other, an SAP system in the DMZ (for example, a Solution Manager system) is able to talk to SAP systems on both sides and can act as a bridge between them.
- A total air gap
With this configuration, there is no possibility of having a bridging SAP system that can talk to both the low and high sides. There is, however, likely to be some method of transferring files between the two side. This often takes the form of a secure FTP connection between the two sides, utilizing a very small set of highly secure network ports.
- (A third configuration – what I call a vacuum gap – is also possible. Here there is absolutely no way of even transferring files over the network between the two sides. If files need to be transferred, then they need to be downloaded to some kind of portable media and moved – by an actual person – to a frontend on the other side that enables them to be uploaded.)
Originally, ActiveControl was designed to act as the single, central coordinating system for transports, and naturally, this requires the ActiveControl Domain Controller to be able to talk to all systems in the landscape. With a total air gap this isn’t possible.
Existing Support for Non-Air Gap Configurations
Of course, ActiveControl can easily handle a standard, non-air gap configuration. What many people don’t appreciate is that it can also, out of the box, handle a bridged air gap scenario. For example, if the SAP system in the DMZ is used as your ActiveControl Domain Controller, then ActiveControl can of course talk to all systems. Assuming that production has a separate /usr/sap/trans, then when ActiveControl is asked to import a transport into production, it will:
- Connect to production and see if the transport files are in /usr/sap/trans
- If they are not (and they won’t be at this stage), it will then connect to the development system to see if it can find them there.
- Having found them, it will use standard SAP RFC to pull them across from development, through the ActiveControl Domain Controller and drop them into the production /usr/sap/trans.
- It can then kick off the import.
All of this can be done with absolutely no special configuration in ActiveControl.
A total air gap, however, is a different story. Customers with this configuration that we have spoken to have several problems that they struggle to overcome:
- Reliably transferring files between the two sides
- Controlling the flow of transports between the two sides
- Being able to report on the status of changes, which may require being able to “see” across both sides (especially where, for example, developers only have access to the low side, and the business only has access to the high side)
- Synchronising change information
As with many customers who use the native SAP TMS, these customers often end up writing and maintaining bespoke utilities to perform the technical functions that TMS can’t manage, as well as putting in place labor-intensive manual processes to allow for the complexities of the environment.
Customer Collaborations: A New Solution is Born
Working closely with one of our customers that operates an air gap environment, we have developed an air gap solution that:
- Allows for the synchronization of key configuration data between two ActiveControl Domain Controllers (one in each security zone) using elements of ActiveControl’s existing Dual Domain Controller functionality.
- Allows for ActiveControl “documents” (Business Tasks and Transport Forms) to be created in either security zone and synchronized to the other side.
- At the appropriate time based on the customer’s approvals workflow, packages transport files (datafiles and co-files) alongside relevant ActiveControl information so that it can be picked up by the customer’s file transfer tool and automatically transferred to the other security zone, where it is uploaded to the ActiveControl Domain Controller on that side.
- Is configurable, so that ActiveControl can meet the needs of customers’ differing security and air gap infrastructure requirements.
ActiveControl’s new air gap solution therefore extends its industry-leading SAP change management capabilities to be able to deal with the most stringent security requirements.
For more information, get in touch with us for a demo on this unique new capability.