In many cases, when companies decide to take a service-oriented architecture (SOA) approach to their IT environment, they focus on design time, service definition, and governance. But as SOA landscapes mature, it becomes increasingly important to also consider practical operations and lifecycle management, including how to successfully transport objects, such as software components or enterprise services, from a development environment to a productive environment. Keep the following points in mind for SOA lifecycle management:
- SOA landscapes are frequently heterogeneous, spanning multiple ABAP and non-ABAP systems.
- The very nature of the service paradigm — providers and consumers working on different systems — can be challenging. You can have a central repository and registry with objects that can be reused in multiple contexts.
- Given these aspects of an SOA landscape, changes can have a significant impact, so change management requires particular attention. And as your landscape becomes more complex, you need to ensure that changed objects are transported consistently throughout the environment.
In this article, we’ll use an example to outline some of the key challenges of lifecycle management in an SOA environment and to describe how SAP NetWeaver tooling — the enhanced change and transport system (CTS+) — helps you address them.
What Do We Mean by SOA Lifecycle Management?
With SOA, several systems may be involved in setting up and using a complete business process. For example, SAP NetWeaver Composition Environment (SAP NetWeaver CE) is used for modeling the process; an Enterprise Services Repository (ES Repository) is needed for defining related services; and ABAP systems store business data. SAP recommends that you have at least a development system and a productive system for each application involved. And it’s cr itical to make sure that the exact functionality you created in your development system is completely transported to the productive landscape.
Ensuring that transports are successful is one aspect of lifecycle management; you should have an efficient solution for managing them. Developers need to be able to collect and bundle objects that they have created to export them to the productive landscape. And an administrator of the quality assurance (QA) system — if you have one in your landscape — needs to review the objects that are imported. Both developers and administrators want to know whether a transport was successful and, if it failed, what caused the error.
In the past, the tooling for a transport has been quite heterogeneous. For example, when creating objects in SAP NetWeaver CE, you would use the SAP NetWeaver Development Infrastructure to store sources and set up transport landscapes for transporting Java applications. In addition, you would use the CTS of SAP NetWeaver Application Server (SAP NetWeaver AS) ABAP to transport the ABAP parts of your business process — thereby using different tools for transporting connected functionality.
To streamline transports and also support administrators in monitoring them, SAP has enhanced the CTS of SAP NetWeaver AS ABAP — called enhanced CTS (CTS+) — so that it can be used for both ABAP and non-ABAP transports. For example, if you change a service in the ES Repository, you could use enhanced CTS when exporting the appropriate change list; for ABAP coding, you can continue using CTS without any process or tool changes. Thus, you use only one central tool to manage transports for very different systems. Developers continue using the workbenches they already know and then use CTS+ to export objects. And now administrators can more easily monitor what objects have been transported to which locations and what objects are still in the queue.
Managing a Business Process Change: A Practical Example
Consider a business process for approving internal IT equipment requests. What if you need to add an additional step to the process? After developing objects to change the process, you’ll have to transport them to your productive system. Here we’ll walk through how to do this in an SOA landscape.
For this example, we created a business process with SAP NetWeaver Business Process Management (SAP NetWeaver BPM) that allows a user to enter requirements for ordering new laptops for his department.1 On one user interface, he can check the specifics of each laptop by entering a product ID and description. This functionality is implemented as a custom-created enterprise service, with its interface modeled in the ES Repository and its implementation residing on an ABAP back-end system. Once the user enters the purchase request, the business rules functionality of SAP NetWeaver BPM determines, based on investment volume and country, whether an approval is necessary. The purchase approver then reviews the order and either approves or rejects it. If approved, a purchase order is created.
Now SAP NetWeaver Process Integration (SAP NetWeaver PI) capabilities come into play: When the purchase order is created, an SAP NetWeaver PI process is triggered, creating a sales order on a legacy supplier application. The process ends after the sales order confirmation is sent.
Consider that the business user now wants to change the process slightly so that the response message also returns the availability of the laptops — Out-of-Stock, In Stock, Back Ordered, or Special Order. Special Order refers to products that fall in a unique category and cannot be ordered by the default procedure; instead, an IT manager must grant a second approval.
The first change that needs to be applied to the original process implementation is an additional “Availability” field for the ES Repository service interface (see Figure 1). With the addition of this new field, the back-end ABAP implementation of the enterprise service also needs to be adjusted, which means that a new change request for this ABAP object will be generated and must also be transported to the productive system.2
||The new structure of the output message for obtaining product details, enhanced with the Availability field, within the ES Repository service interface
Figure 2 illustrates the modified business process. You can’t see that, behind the scenes, the changed enterprise service is called, but you can see that the approval step for Special Order items now appears in the process flow. To run that process in your productive system, you need to make sure that all the changed objects find their way into production.
||Modeled business process with additional approval for a Special Order
Transporting Objects Using One Method: CTS+
Let’s consider the impact these process changes have on the lifecycle management of the application; here is where CTS+ enters the picture. CTS+ allows us to use one transport method for the all systems involved in our scenario.
Here we’ll discuss the following three steps involved in transporting the process changes from the development system to the productive system:
- Choose and configure CTS+.
- Export objects from the development system.
- Import objects into the productive system.
1. Choose and Configure CTS+
The first step is to decide which s ystem to use for CTS+. For purely non-ABAP transports, SAP recommends using SAP Solution Manager, which is available to every customer for maintaining and monitoring systems.
In our example, we’re using SAP Solution Manager 7.0 (with updates from enhancement package 1) as the Domain Controller and for managing the transport requests for the CE systems shown in Figure 3. Another option is to reuse an existing Domain Controller — you might already have one for the ABAP parts of your SAP NetWeaver PI systems.3
||Sample landscape for lifecycle management in an SOA environment; this diagram illustrates the landscape in our example
We’re using Change Management Services to transport changes to our process model directly from within SAP NetWeaver Developer Studio. This allows us to transport the objects containing the changed sources instead of the complete software component. Additional configurations are required.
After completing the basic configurations, the administrator can create system landscapes in transaction STMS of SAP Solution Manager. System landscapes put the systems involved in the process in a row: First, you develop your applications in the development system. After that, you’ll want to transport objects, for example, into your QA system, and then into the productive environment. To do so, you need a transport route from development to QA and another route from QA to production — these three systems are an example of a system landscape.
For our CE7 development system and CE1 productive system shown in Figure 3, we have to create new non-ABAP systems. And for the PI landscape, we can add the Java stack to the existing ABAP systems. When creating a new non-ABAP system or adding a Java stack, a wizard will appear (see Figure 4).
||Creating a non-ABAP system within transaction STMS
The administrator can choose whether to create a source system or a target system. You export objects from a source system and import them in the target system. In our example, CE7 must be created as a source system — this is the system from which we’re exporting what we developed. CE1 is the target system — this is our productive system where we would like to import all new functionalities.4
In addition, the administrator must choose the “Create Development Configuration” option for both CE7 and CE1 (refer again to Figure 4). (When you use Change Management Services, the development configuration is not created in the SAP NetWeaver Development Infrastructure, but rather directly from within CTS when configuring your systems.) The development configuration contains information on what is going to be developed and where the sources and builds are stored.
When developing your own Java applications, libraries are necessary to perform a build. Because we are transporting sources, we have to perform a build in each system, so we must have the libraries available in each system. SAP delivers the libraries, which need to be imported into each system. Here the CEU upload system (refer back to Figure 3) becomes relevant in our example — this system is used to upload the libraries required for the build. There is no actual server behind this system; we only use it to create a transport request containing the basic libraries. This is also why there are two routes between CE7 and CE1 in Figure 3 — one is the delivery route for the libraries and the other is the consolidation route for the Java development.
After completing the configurations in the transport management system (TMS), the administrator must make the applications “CTS ready” by creating a destination on each development system that connects the application with the system used for transports.5
2. Export Objects from the Development System
After the administrator completes the configurations, developers can start using CTS+ when exporting changed or newly created objects. In SAP NetWeaver Developer Studio, they can download the development configuration of the source or the development system of the Java system landscape — CE7 in our example — and then find a transport request when they release their objects.
Let’s continue our example. To show how CTS+ is involved in exports, we’ll look at how the changed service interface in the ES Repository is exported. First, the developer must choose how to export the objects; in this case, he selects the default mode, “Transport Using CTS” (see Figure 5).
||Selecting the source of the export int he ES Repository
Second, the developer chooses the objects to export. (Note: This step is the same whether you use CTS+ or not.)
Third, the developer can see information on the transport request that’s going to be used. Here, there’s an option to create a new transport request or change the one displayed via the “Create/Change Transport Requests” link (see Figure 6).
||Selecting the transport request in the ES Repository
Next, a pop-up window summarizing the export will appear (see Figure 7).
||An export summary details the object that is ready for transport
Finally, the developer must release the transport request. One transport request can contain one or more objects. For your SAP NetWeaver PI objects, this means that you could use the same trwansport request for both ABAP and non-ABAP objects. By releasing the transport request, the developer closes it. Now the transport request can be imported into the next system — in our example, XLI, our productive system for SAP NetWeaver PI.
3. Import Objects into the Productive System
An administrator of the productive system is responsible for importing objects, using the queues for the respective systems in the TMS (see Figure 8).
|A list of systems in the TMS; by double-clicking on one item, you can see the requests
The administrator could then look at the queue of one or several systems and either start single imports or import all of the requests that are currently in the queue. The mechanisms available here are the same as for all ABAP transports. The administrator can use schedulers within the TMS; also, after importing a request, he can view the import log for imports in Java systems in CTS+. For non-ABAP systems, the files that are attached to a transport request are handed over to the respective deployment tool. All objects that are part of the transport request are deployed automatically when the administrator imports the transport request.
We have seen how our changes to the business process have been exported from the development system and imported into the productive system using CTS+. End users can now use the modified business process in the productive system.
As your SOA landscape becomes more complex, lifecycle management becomes even more critical. With CTS+, you have a central tool to manage ABAP and non-ABAP transports to ensure that objects are consistently and successfully transported throughout your heterogeneous IT environment.
Dr. Susanne Rothaug (firstname.lastname@example.org) is a Product Manager on the SAP NetWeaver SOA middleware team. She joined SAP seven years ago and has worked on various areas within SAP NetWeaver product management. Currently, Susanne focuses on process integration and SOA topics. She is a regular speaker at major SAP events including SAP TechEd.
Karin Sudrow (email@example.com) is a Product Manager on the SAP NetWeaver software logistics team. She joined SAP nine years ago and has worked on various areas within SAP consulting and SAP NetWeaver product management. Karin currently focuses on CTS topics, and she speaks regularly at major SAP events.
1 For details on using SAP NetWeaver BPM, see “Gain Control of Your Critical Business Processes: Design, Document, and Deploy Them with SAP NetWeaver Business Process Management” by Donka Dimitrova and Ralf Schaub in the January-March 2009 issue of SAP Insider (sapinsider.wispubs.com). [back]
2 The details of the modified ABAP coding are beyond this article’s scope. For now, just keep in mind that coding changes are required, and these changes must be transported along with the ES Repository object. [back]
3 Note that to use CTS+ for non-ABAP transports, the administrator needs to perform some component configurations in advance; review the “Prerequisites for Non-ABAP Transports” section in the SAP Help portal to learn more. [back]
4 Visit the SAP Help portal to find out more about the different configuration options and parameters for non-ABAP transports. [back]
5 Visit http://help.sap.com/saphelp_nw70ehp1/helpdata/en/b7/c05c7d89054705bf890bf292aad997/frameset.htm to learn how to configure the destination service. The SAP Developer Network also provides how-to guides that describe the configuration of CTS+ for different applications. [back]