If you explored Developer Extensibility in the recent releases of SAP S/4HANA Cloud public edition, you might have seen that there is a new option to deliver applications which is called multi-off.
But is this the only case when multi-off can be used? What are the options and constraints if you use it in other cases?
So first and foremost: the primary transport mechanism inside a 3-system landscape (3SL) for customizing, key user, and developer extensions is described in 3-System Landscape and Transport Management. This is the way of transporting that you should use inside your 3SL. With this, you can make sure that all dependency checks between developer extensibility and customizing or key user extensibility are executed correctly. This transport mechanism does not make use of gCTS respectively of what is described as multi-off in the documentation.
Multi-off is made for:
- Delivering applications from a TDD development into a 3SL
- Take over coding for customer specific development (e.g. Partner Templates)
- Delivering an app from one 3SL to another one.
Let’s look into these three in more detail:
Delivering applications from a TDD development into a 3SL
This is what you maybe found or might have read concerning multi-off already. It is used to deliver coding from a source side TDD system into a target 3-system landscape (3SL) with the help of a Git repository as shown in the next figure:
If you haven’t heard about it, but would like to know more, you can find information on the SAP Help Portal at Multi-Off Delivery.
Take over coding for customer specific development (e.g. Partner Templates)
If the above is your use case and you have imported an app into your system that another party developed for you, you might come to the point that you need to extend or change what you got. The ideal solution in this case would be if you used extension points provided by your partner that you can use to program something on top. If this is the case, you can work with customizing, key user, and developer extensibility and transports as described in 3-System Landscape and Transport Management. With this, you can be sure that dependency checks and the like that are available in there can be used.
But if you need to change the coding that you got delivered e.g. because it is just a template or a toolbox that serves as a basis for customer specific development extensions, then you need to use multi-off. This is because the coding that you got is part of the package and software component ZPARTNER. All the objects that are located in there have to make use of multi-off and can only be transported using multi-off.
Please also note that in this case, you need to decouple from the repository from where you initially pulled the application and use your own repository instead. This is because you might not have write access for the original repository and even if you had write access, you still would not want to push your changes to that repository. The consequence of this is that you cannot receive any updates from your provider anymore. This means that you cannot pull any later commits from that original repository directly anymore. If you kept the original repository in addition and then pull later commits after you did changes, this would mean that your changes will get lost.
If this is what you want, you need to configure multi-off in your 3SL. For configuring multi-off on the development system in your 3-system landscape, please go through the topics below Setup for Multi-Off Delivery on the SAP Help Portal.
Before you start developing, you need to fill the repository with the content that you received from your provider. In this case, it is not sufficient to just push the new and empty package to your repository. You also need to push all its objects. The content of a repository can only be pulled in a target system if it contains the complete objects. Partial objects are not supported. (For sure, later in the process, only partial objects care pulled, but as a starting point the complete objects are needed).
As soon as this is done, you can start with changing the coding. All your packages need to be sub-packages to ZPARTNER. Make sure that all your packages (and objects) are below ZPARTNER right from the beginning when you create them. It is not possible to move them later on. We recommend that you use a naming convention for your objects that make clear that these objects are custom developed. Note that changes done as key user extensibility cannot make use of multi-off and that dependencies cannot be checked.
The chapter Establishing a Branching Strategy gives some ideas for setting up branches inside your repository. For sure, you should think about the branches that you would like to use. But as you are not going to deliver your development to any third party, it is not required that you take care of a dedicated delivery branch.
Delivering an app from one 3SL to another one
If you have several 3-system landscapes in place and need to move your coding from one to another, you would also need to use multi-off as transport mechanism. Let’s say for example, your IT department owns one landscape, and several business departments or countries use other ones. Some basic coding is maybe created by IT, but business departments or countries need to customize the systems a little bit differently – that is why they cannot run in one landscape.
You can use what is described in the multi-off scenario for this use case. But take into consideration that multi-off only supports development objects – so what is known as Developer Extensibility. What is done in customizing or key user extensibility cannot be managed via gCTS in multi-off. Dependency checks between development objects and key user extensions or customizing are not available when you use gCTS. The transport mechanism described in 3-System Landscape and Transport Management does not support transports between landscapes – they are made for transports within one landscape. This means that you need both mechanisms: Multi-off to transport development from one landscape to the other and 3-System Landscape and Transport Management to transport customizing and key user extensions within one landscape. Note that dependency checks between your custom development and key user extensions or customizing cannot be done in this case.
If you decide to use the multi-off option in a 3SL setup to be able to share your development between landscapes, there are some things that you should be aware of concerning setting up multi-off. Please note that it is not sufficient to work only with the multi-off documentation about the target side. Some of the ‘to dos’ for the source side are also relevant for the development system of the 3SL landscape if you start developing there (and don’t get the apps delivered, for example from a partner).
For configuring multi-off on the development system in your 3-system landscape, please go through the topics below Setup for Multi-Off Delivery on the SAP Help Portal. As soon as this is done, you can start with the Extension Development. The chapter Establishing a Branching Strategy gives some ideas for setting up branches inside your repository. For sure, you should think about the branches that you would like to use. But as you are not going to deliver your development to any third party, it is not required that you take care of a dedicated delivery branch.
In the documentation, we talk about namespaces and the package ZPARTNER. If you plan to use gCTS in a pure 3-system landscape, please be aware that namespaces are not yet supported for your development. Still, all your packages need to be sub-packages to ZPARTNER. Make sure that all your packages (and objects) are below ZPARTNER right from the beginning when you create them. It is not possible to move them later on. We recommend that you use additional naming conventions for your objects that make clear that these objects are intended for delivery to other landscapes – something like e.g. ZCross_xxx for all objects below ZPARTNER.
For the target systems – so test and production of your 3SL or the target landscape – please follow what is described in Consuming ABAP Extensions in Multi-Off Delivery on the SAP Help Portal. For sure the sections about receiving information from your supplier (like repository name, credentials etc.) are not relevant when you remain within your 3-system landscape.
In all cases, you need to bring your own Git. There is no Git provider available in the public cloud. You have to make sure that your systems can reach your Git server and that the provider of that Git server is supported by gCTS with all the functionality that you need (best supported is GitHub, Gitlab and many others also work with the exception of showing the remote version in the conflict resolution editor, and sometimes issues with validating users in the credential store).
To summarize things:
You can use gCTS in three-system-landscapes for the use cases described above:
- Only if you want to transport your development from one landscape to another – not within one landscape.
- All objects need to be located in packages below the ZPARTNER package.
- Namespaces are not yet supported in pure 3SL setups.
- It is not possible to move objects from ZCUSTOM_DEVELOPMENT to ZPARTNER or vice versa.
- In gCTS, there is no option to transport key user extensions or customizing. Also, dependency checks are not available.
- SAP Managed Tags:
