If you have finished the design work and testing of your production process, the next step is to move it into production and use it in your business scenario. For this, SAP DM offers two mechanisms. You can use the export and import function of the Production Process Designer or, since the 2411 release, SAP Cloud Transport Management is available for the same.
To leverage SAP Cloud Transport Management, you need to subscribe and configure the service on the Business Technology Platform first. Afterward, you can then trigger the transport from Production Process Designer. In this course, we will only discuss the export-import function of SAP DM more closely. To find out more on SAP Cloud Transport Management for production process designs, please consult SAP Help portal.
The usage of export-import is simple. (1) You select the production processes you want to export. (2) When selecting Export, the system asks you to create a password for the export file. After selecting the password, a file is downloaded to your local drive. You can then log off from your quality or source system and log into your productive or target system. (3) In the target system, you select Import, reenter the password, and the design becomes available under (4) My Import. Caution: The design is not deployed yet and might also need adjustment before being deployed depending on the services you used. (Some points which should be checked will be discussed in the next paragraph.) To finish up the import, you deploy the process in the target system the same way you did in the development system.
Moving Production Processes Restrictions
The first restriction on moving production processes is that the systems need to have the same version. In other words, it is not possible to transport production processes from quality to production during the two weeks of release testing for every release.
The reason for this is that the quality landscape already offers the latest API versions, which might not be available in the productive tenant yet. When you plan your go-live, you should consider the release dates and how these impact the testing of developments and transports. In most case, you should try to avoid scheduling a go-live in the two weeks of release testing.
Production Process Dependencies
As well as the release time frame, you also need to consider the following dependencies of your production process:
- If you have used custom services in your production process that you have registered in the service registry, you need to recreate the Web server and the destination on the Business Technology Platform manually in the productive environment. This is because you almost certainly want your call to arrive at a different endpoint for the productive environment. (The details for the Service Registry will follow in the next unit.)
- You need to carefully design the sequence in which you import the production processes into the productive system. For example, you have created one central design offering helper functions to all other designs by publishing the production processes and calling them from other designs. This design with the helper functions needs to be imported and deployed in production first. Later, you can then deploy the calling designs.
- If you have stored configuration data in script tasks, for example, the path to a machine indicator or other configurations which are different in the production environment, you will need to adopt this. If you didn't do so, it is even better.
- Lastly, if you have used machine indicators or local indicators, these need to be created in a productive environment, and the process needs to be adopted to refer to the correct indicators before you can deploy the design. If this does not tell you anything at this point, don’t worry. It is meant as a hint in case you have already used indicators and are about to set up your machine integration.
There are not only objects the production processes are dependent on but also objects building on to production processes which are not included in the transport file:
- First, like the published production process that you depend on, there might be calling production processes as well if you published the production process for external calls. So, you might want to check if you need to import any calling production process designs as well. For the dependencies between production process designs in both directions, it is advisable to maintain a cutover list. (You will also learn more on publishing production processes in the next unit.)
- The same is true for all other calling objects of the production process design. None are included in the import and need to be created or need to be checked in the target environment. The calling objects are as follows:
- Production Operator Dashboards
- Automatic triggers
- Configured alerts
- Other production processes (see above)
- Third-party calls