Multi-Off is an option to deliver software that has been introduced in SAP S/4HANA Cloud Public Edition in 2308. Multi-off delivery lets you develop ABAP extensions in an SAP S/4HANA Cloud landscape and use the Git-enabled Change and Transport System (gCTS) to deploy them on any SAP S/4HANA Cloud target landscape that isn't connected to your landscape. If you need more information about Multi-Off and its purpose, please refer to the SAP Help Portal at Multi-Off Delivery
If you use Multi-Off for delivering your development in SAP S/4HANA Cloud Public Edition, some additional cloud rules apply. They differ from what you might be used to if you already know the gCTS from S/4HANA on premise. The rules and the checks have been introduced to make development and gCTS in the cloud safer.
Developments with ABAP cloud follow some specific requirements concerning object types and language elements that are allowed to be used. As gCTS involves using Git - no news but.. – it is possible to create commits in repositories from other sources than an ABAP system in the cloud. But then, it is not granted any more that all objects and commits follow the ABAP language rules . Therefore, SAP must check the commits.
In addition, we would like to make sure that your systems, especially your production systems, are safe and work fine as much as possible.
This is why we only allow pulling into target systems if the sequence of order of the systems is kept. This means only what has been pulled into the Development system can be pulled into the Test system and only what has been pulled into Test system can be pulled into the Production system.
These are the checks that we do – but what are the consequences for you both as a software provider and as a consumer of applications that are not issued by SAP?
The basic principle is that only commits can become active in a system that have been active on predecessor system beforehand .
Let’s use the standard landscape as show case to explain what is going on:
The landscape is not restricted to what is shown above. We only used this example in this blog post to explain what is happening where. Another DEV system can also serve as the source. And you can also use Multi-Off in just the three systems of the 3SL. But in whatever landscape you use Multi-Off, the checks within 3SL are always in place.
In our sample landscape, we have on the source side, a development system, where we develop our app. This app shall then be shipped to the customer – the target side – where a landscape consisting of a development, a test and a production system is in place.
To start simple, let’s say that we use one repository with one branch. This is not the recommended way to set things up, but to explain the checks and what the consequences are, let’s use this set up for a second.
The situation in our systems on the target side is shown in the following picture. It shows the three systems and the commits that are or have been active in the respective systems.
In our DEV system, we have the commit M4 active. In TST, M3 is active and in PRD, currently M1 is active. As it is only possible to activate commits in follow-on systems that had been active in predecessor systems, it is not possible to activate the latest commit M4 in PRD. The commit M3 is the newest one that can be pulled into PRD (M2 is possible as well, as this commit had been active in the past in TST as well). In TST, M4 can be pulled. After that has been done, it would also be possible to pull M4 into PRD. M2 and M3 don’t have to be pulled before.
Let’s assume further that you work with several branches : one branch for development called Feature that is the active one in the source system while you are developing and where you push to during your development process. In addition, at least one other branch is needed that is used to deliver custom-ready coding and that is connected to all the systems on the target side. For sure, you can also work with more branches. But to keep things simple, let’s stay with these two for now.
In the picture above, the branch Feature has been split off from Main. New developments are done in in the source system (named TDD in here) and when these are ready, Feature is merged into Main. This latest commit in Main is then available for the target side and can be pulled into the systems. It is now important that this new commit is first pulled into DEV, then in TST and only after that in PRD. Other sequences are not allowed and will lead to errors that the commit could not be verified.
But this does not mean that the latest commit must be active in all systems on the target side. It only means that only commits that had been active before in all predecessor systems can be pulled into follow-on systems. For example, the DEV system can be on a later / newer commit than the one that you would like to pull into PRD – if that commit had been active in PRD at some time in the past.
In the following picture, we show one example to illustrate the requirement and process:
In this example, let us focus on the branch Main. There are several commits that were created by merging the branch Feature into Main. The commits in the Main branch have been created via merges. The source system, where development is done, is using the Feature branch for commits, to merge into Main, the branch is switched in there for a short time. The systems in the 3SL are all connected to the Main branch and pulls can only be done from there.
| DEV | TST | PRD | |
| M1 | yes | yes | (is active) |
| M2 | yes | Yes (because a later commit has been pulled) | Yes (because a later commit has been pulled to TST) |
| M3 | yes | (is active) | yes |
| M4 | (is active) | yes | No (has never been pulled into DEV and TST) |
| M5 | yes | No (has never been pulled into DEV) | No (has never been pulled into DEV and TST) |
As you can see, it is not required that each commit be pulled into each system. But each commit that shall be pulled into a successor system has to be pulled into all predecessor systems before. For sure, it does not mean that the changes that you did on a commit that was never pulled into a system will not be added to the system. Implicitly, all changes that were done in previous commits will be pulled together with the later commit.
This also does not necessarily mean that it makes sense to activate older commits in systems that are already on newer ones, but the table aims to show what is possible, to make clear why a certain commit is allowed to be pulled in a certain system. It is completely ok to leave out some commits in between. It only has to be clear that later systems in the row cannot pull a commit if it has not been pulled into all predecessors beforehand.
In addition, the branch is not important. If you use different branches on the target side – e.g. one for DEV and another one for TST and PRD, still any commit can be pulled into PRD that had been active in DEV and TST before. It is not important from which branch the commit is taken. When you merge branches, all commits from the branch that you merge into the active one are added to that branch and the verification of that commit is valid in each branch.
Please also consider the following aspect : when you add a repository to a system and clone it, the latest commit of the default branch is cloned to the system. This only succeeds if the latest commit has been active in all predecessor systems before you execute the clone. Let’s look back at our example above and assume the following: the repository ‘extensionRepo’ has been cloned to DEV and TST somewhen in the past. In TST, currently the commit M3 is active, all later commits never have been pulled into TST. But the current state of the main branch is commit M5. If you now connected PRD to extensionRepo and cloned it, cloning would fail as M5 never has been pulled into TST. So, in this case, before cloning, M5 should be pulled into TST and only then cloning in PRD should be done.
Troubleshooting
Let’s start with some things that you should not do before we start with what you can do:
- Do not delete the repository in any system. This would also delete the knowledge about which commits had been imported where. In the actual system, it is always only possible to activate commits that had been active in the predecessor systems beforehand since the repository had been cloned.
- Do not try to pull again by pressing Update to Latest on the Commits tab. The local repository is on the latest commit, so no new deployment will be done as no difference between the active and the latest commit can be calculated.
But what if you - despite all the reading before in this blog post – accidentally ended up with an error message when cloning or pulling a commit that the commit could not be verified (and this is because you did not pull the required commit in the predecessor system(s))?
- Pull the required commit - either by using a tag or the commit directly – in the predecessor system(s). So if you like to pull something new into the test system, make sure that it had been pulled into development before. If you would like to update your production system, make sure that what you need in production had been pulled into development and test before.
- Go to the system and the repository where the issue came up. (Do not try to pull again by pressing Update to Latest on the Commits tab).
- Open the Objects tab. Click Deploy.
- In the pop-up, choose Current Commit and click Deploy.
- SAP Managed Tags:
6 Comments
