Thursday, November 12, 2009

Authorizations in Change Management Service

To grant authorizations, Change Management Service (CMS) uses the User Management Engine (UME) in SAP J2EE Engine.

You can use CMS to perform the following UME actions. These UME actions allow you to create UME roles with special authorizations. For examples of roles in CMS, see Roles in Change Management Service .

The following UME actions are defined:

UME Actions in CMS

UME Action

Permitted Functions

CMS.Display

This UME action grants you access to CMS.

This UME action serves as the basis for all further UME actions.

CMS.ExportOwn

Release your own activities in SAP NetWeaver Developer Studio

CMS.ExportForeign

Release other users’ activities in SAP NetWeaver Developer Studio

CMS.Transport

Check-In

Add to queue

Unlock queue entries

Restore system state

Import

Import check:

Assemble

Forward to another track (the authorization for this function is checked in the target track)

CMS.CriticalFunctions

Delete queue entries

Lock/Unlock Import Queue

CMS.Approve

Confirm/Reject

CMS.ConfigureDomain

Save domain

Update CMS

CMS.CreateTrack

New

Save (new track)

Save as

CMS.ModifyTrack

Save (existing track)

Add/Delete runtime systems

Delete

Add/Delete track connections

CMS.OverAllTracks

UME action that allows you to edit all tracks, independently of track-specific UME actions

CMS.UserAdmin

UME action for processing track-specific UME actions

CMS.Administrate

Composite UME action that includes all other UME actions

Note

The UME actions CMS.Export and CMS.Configure have now been replaced by more configurable authorization modules.

Previous UME action

Replaced by the following UME actions

CMS.Export

CMS.ExportOwn

CMS.ExportForeign

CMS.Configure

CMS.ConfigureDomain

CMS.CreateTrack

CMS.ModifyTrack

End of Content Area

Roles in Change Management Service

For individual descriptions of the UME actions that you can use for your work in Change Management Service (CMS), see Authorizations in Change Management Service.

The following is a list of useful roles in CMS:

CMS Role Types

Role

Assigned UME Actions

Privileges of the Role

Guest

CMS.Display

Display import queues and transport histories in the Transport Studio

Display details of queue entries and logs.

Display configuration files in Landscape Configurator

Developer

CMS.Display

CMS.ExportOwn

Has all Guest privileges.

Release own activities in SAP NetWeaver Developer Studio

Quality Manager

CMS.Display

CMS.Approve

CMS.ExportForeign

Has all privileges of Guest.

Approve and reject software components in Transport Studio. Release foreign (third-party) activities in Developer Studio

Operator

CMS.Display

CMS.Transport

CMS.CriticalFunctions

Has all privileges of Guest.

Perform test imports, check-in, assemble, unlock queue entries, restore system state

Perform the critical functions Delete Queue Entries, Add to Queue, Import Older Versions, Forward to Another Track.

Configurator

CMS.Display

CMS.CreateTrack

CMS.ModifyTrack

Has all privileges of Guest.

Perform all configuration functions at track level in Landscape Configurator

Administrator

CMS.Administrate

Combines all CMS privileges in one role

Note

Users who have been assigned the CMS administrator role should also have J2EE Engine Administrator rights. All users who are CMS administrators should therefore be assigned to the J2EE Administrator group as well.

Note

To configure the domain in CMS you need to create a CMS User. As well as the administrator rights for Component Build Service (CBS) and Design Time Repository (DTR), this user also needs the write permission for System Landscape Directory (SLD).

End of Content Area

Configuring the Change Management Service

Use

Using the Change Management Service (CMS) with SAP NetWeaver usage type PI is optional. You can use it to transport Integration Builder objects. If you want to use CMS, you must perform some configuration steps first.

Note

You can configure CMS for either repository objects or directory objects independently from each other.

The following sections only cover a basic and initial configuration of CMS for use with PI.


Recommendation

Do not use CMS and the Change and Transport System (CTS) at the same time, except when you migrate from CMS to CTS or vice versa.


Deploying the CMS Component

The CMS component is part of the SAP NetWeaver Development Infrastructure (DI). You find the sources for the DI deployment on SAP Service Marketplace at service.sap.com under SAP Support Portal ® Downloads ® SAP Software Distribution Centre ® Download ® Support Packages and Patches ® Entry by Application Group ® SAP NetWeaver ® SAP NETWEAVER ® SAP NETWEAVER 7.0 ® Entry by Component.

1. Choose Development Infrastructure.

2. Select the following components:

DI Change MGMT. Server 7.00

DI Component Build Server 7.00

DI Design Time Repository 7.00

3. Download the most current Software Component Archive (SCA) of each component.

4. Deploy the downloaded SCAs with your Software Deployment Manager (SDM).

Defining CMS Communication Users in PI (optional)

Different PI systems probably use different Integration Builder service users and passwords for communicating with CMS. If you want each of these systems to use the same service user name and password for CMS communication, but you do not want to modify each system’s service users, you can specify dedicated service users for CMS communication. To do so, use the following parameters in the exchange profile:

com.sap.aii.repository.serviceuser.name.cms

com.sap.aii.repository.serviceuser.pwd.cms

com.sap.aii.directory.serviceuser.name.cms

com.sap.aii.directory.serviceuser.pwd.cms

Do the following to avoid that passwords can be read as plain text in the exchange profile:

...

1. Export the exchange profile.

2. Change type from pwd to string in the file that contains the parameters

com.sap.aii.repository.serviceuser.pwd.cms

com.sap.aii.directory.serviceuser.pwd.cms

3. Import the modified file with option overwrite.

4. Delete the file that contains the readable passwords.

If you do not specify these parameters, the names and passwords of the Integration Builder service users (for example, PIDIRUSER and PIREPUSER) specified with the following parameters will be used:

com.sap.aii.repository.serviceuser.name

com.sap.aii.repository.serviceuser.pwd

com.sap.aii.directory.serviceuser.name

com.sap.aii.directory.serviceuser.pwd

Maintaining CMS Communication Users in CMS

To maintain the CMS communication user in CMS, perform the following steps:

...

...

1. Access the User Management area of the J2EE Engine of your CMS system and define the following roles and actions:

Role CMSDeveloper with actions CMS.Display and CMS.Export

Role CMSAdministrator with action CMS.Administrate

2. Choose the User Administration tab page of the J2EE Engine of your CMS system and define the dedicated service users for CMS communication you specified in the previous section as CMS users with role CMSDeveloper.

If you have not specified any dedicated service users for CMS communication, use the Integration Builder service users (for example, PIREPUSER and PIDIRUSER).

These service users are used by PI to send data to CMS. Therefore, their passwords must be the same in CMS and PI.

Note

Make sure that the passwords you define for these two users in CMS match the passwords in your PI system. To do so, log on with both users to the J2EE login screen to make sure that the passwords are correct and that they do not need to be changed.

3. Define a CMS Administrator user with the role CMSAdministrator.

It is assumed that the CMS Administrator performs the customizing and the later transports. If you need to distribute administration tasks (for example, approval, transports) to different users, you have to define additional roles and users.

Note

All users you created during the CMS setup must change their passwords at initial logon or must have set the flag No password change required.

Be aware that passwords are case sensitive.


Configuring a CMS Domain in CMS

...

Use the Landscape Configurator and configure

the CMS domain

the CMS server

the System Landscape Directory (as External Server)

Perform the following steps

...

1. Configure a CMS domain for PI in CMS as described in Configuring a Domain.

2. Configure the CMS server as follows:

...

a. Insert the CMS URL (server name and port of the CMS system)

b. Create a CMS user. The user allows CMS to connect to the PI systems.

This user (for example LSADMIN) must be maintained as service user in all PI systems (including SLD) with the same password. It requires the following ABAP roles:

SAP_XI_CMS_SERV_USER

SAP_SLD_ORGANIZER

Note

Either restart the J2EE Engine after you have added the roles to the CMS user or wait until the group assignment has been transferred to the J2EE Engine.

Within CMS, it is assumed that there is only one central SLD for all Integration Builder systems of the CMS domain. If more than one SLD is used by the Integration Builder systems, you should choose the master SLD for the domain definition.

Note

A CMS track can only be defined if all software component versions relevant for the track are available within the SLD of the CMS domain.

If you have installed the SLD on a standalone J2EE Engine (and not on an AS-Java including PI), you have to perform the following steps:

...

1. Use the Visual Administrator and open the component sap-com/com.sap.lcr*sld

2. Add the CMS user (for example LSADMIN) to the security role LcrInstance WriterAll or to the group SAP_SLD_ORGANIZER.

Activating CMS in the Integration Builder

Set or enhance the following exchange profile parameters to activate CMS for use with the Integration Builder. The CMS transport option will then be displayed in the Integration Repository and in the Integration Directory.

Normally, these parameters must be set only in systems that are planned to be inserted into the development tracks. In all other systems, the transport should be organized by CMS.

Integration Repository

To be able to use CMS for repository objects, perform the following steps:

...

1. Ensure that the following parameters are available and set to true in your development and consolidation systems; do not change these parameters in production systems:

com.sap.aii.ibrep.core.cms.enableClTransport=true

Determines that the option of transporting change lists with CMS is provided on the user interface.

com.sap.aii.ibrep.core.cms.enableTransportWizard=true

Determines that the CMS transport is provided by the export wizard.

2. Add the following value to com.sap.aii.ib.client.properties:

com.sap.aii.ibrep.core.cms.*

Note

Do not replace existing values here. Just add the new one.

Integration Directory

To be able to use CMS for directory objects; perform the following steps:

...

1. Ensure that the following parameter is available and set to true in your development system:

com.sap.aii.ibdir.core.cms.enableTransportWizard=true

Determines that the CMS transport is provided by the export wizard.

Note

The transport of change lists with CMS is not supported for the Integration Directory.

2. Add the following value to com.sap.aii.ib.client.properties:

com.sap.aii.ibdir.core.cms.*

Note

Do not replace existing values here. Just add the new one.

3. Ensure that the following parameter is available and set to true in your consolidation system:

com.sap.aii.ibdir.core.cms.enableClTransport=true

Determines that the option of transporting change lists with CMS is provided on the user interface.

Do not change any of these parameters in production systems.

Defining Development Tracks in CMS

For information on defining a development track for PI in CMS,

Specify the tracks as follows:

For the Integration Repository, specify http://:/rep/

For the Integration Directory, specify http://:/dir/

End of Content Area

Configuring the Change and Transport System

Use

Using the Change and Transport System (CTS) with SAP NetWeaver usage type PI is optional. You can use it to transport objects of the Enterprise Services Repository and the Integration Directory. If you want to use CTS, you must perform some configuration steps first.


You can configure CTS for either repository objects or directory objects independently from each other.

The following sections only cover a basic and initial configuration of CTS for use with PI.

More information: Transporting Objects from SAP NetWeaver PI by Using CTS.

Recommendation

Do not use CTS and the Change Management Service (CMS) at the same time, except when you migrate from CTS to CMS or vice versa.

More information about CMS: Configuring the Change Management Service.

Defining CTS Communication Users in PI (optional)

Different PI systems probably use different repository and directory service users and passwords for communicating with CTS. If you want each of these systems to use the same service user name and password for CTS communication, but you do not want to modify each system’s service users, you can specify dedicated service users for CTS communication. To do so, use the following parameters in the exchange profile:

com.sap.aii.repository.serviceuser.name.cms

com.sap.aii.repository.serviceuser.pwd.cms

com.sap.aii.directory.serviceuser.name.cms

com.sap.aii.directory.serviceuser.pwd.cms


These properties are used to change the user and password for CTS and CMS at the same time.

Do the following to avoid that passwords can be read as plain text in the exchange profile:

...

1. Export the exchange profile.

2. Change type from pwdto string in the file that contains the parameters

com.sap.aii.repository.serviceuser.pwd.cms

com.sap.aii.directory.serviceuser.pwd.cms

3. Import the modified file with option overwrite.

4. Delete the file that contains the readable passwords.

If you do not specify these parameters, the names and passwords of the repository and directory service users (for example, PIREPUSER and PIDIRUSER) specified with the following parameters will be used:

com.sap.aii.repository.serviceuser.name

com.sap.aii.repository.serviceuser.pwd

com.sap.aii.directory.serviceuser.name

com.sap.aii.directory.serviceuser.pwd

Configuring the CTS-Based Export

The following properties are used to configure the CTS-based export:

com.sap.aii.[ibrep|ibdir].core.cts.enableClTransport = [true|false]:

This property specifies whether the CTS-based transport should be offered within the change lists area

com.sap.aii.[ibrep|ibdir].core.cts.enableTransportWizard = [true|false]:

This property specifies whether the CTS-based transport should be offered within the Transport Wizard area

To activate one of these properties, add (not replace) the following string to the client property com.sap.aii.ib.client.properties:

‘, com.sap.aii.ibdir.core.cts.*, com.sap.aii.ibrep.core.cts.*’


com.sap.aii.ibrep.core.cts.enableTransportWizard=true

com.sap.aii.ibrep.core.cts.enableClTransport=true

com.sap.aii.ibdir.core.cts.enableClTransport=true

Transporting Objects from SAP NetWeaver XI by Using CTS

Use

With the Change and Transport System (CTS) you can transport the following objects from SAP NetWeaver XI with the CTS transport request.

Integration Repository design objects

Integration Directory configuration objects

ABAP Mappings


ABAP proxies for Integration Repository message interfaces are usually created in another SAP system that belongs to the Integration Repository. A transport in which message interfaces from the Integration Repository and corresponding ABAP proxies are to be transported in a transport request is therefore not possible with the procedure described here.

More information: Non-ABAP Transports in Change and Transport System (BC-CTS)

Prerequisites

There are two variants for SAP NetWeaver XI transports using CTS with the following system prerequisites:

For systems based on SAP NetWeaver XI 7.0 (after SPS13), transports can only be executed using CTS without having to manually copy the transport files. This case is described in this documentation.

For systems based on SAP NetWeaver 2004 (after SPS14), you can implement CTS on a separate system based on SAP NetWeaver 7.9 SPS12 as Transport Server and execute transports in this way. In this case, however, the export files must be copied manually into a transport server directory. Also, up to SAP NetWeaver 7.0 SPS11, you must define two transport routes.

One for ABAP objects of SAP NetWeaver XI system (SAP system in TMS: virtual system)

One for non-ABAP objects of SAP NetWeaver XI system (SAP system in TMS: non-ABAP system)

More information see the SAP Developer Network under https://www.sdn.sap.com/irj/sdn/xi ® How-to Guides ® End-to-End Process Integration ® Enabling Platform Interoperability ® How to Transport Repository and Directory Content Using CTS+ (SDN user required).

In addition the CTS transport must be activated for each SAP NetWeaver XI system that is to be connected with the CTS transport landscape.

Procedure

...

1. Consider in advance which systems are to be involved in your transport landscape for the transport of objects from SAP NetWeaver XI. A basic configuration is necessary for all these systems to be able to operate CTS with SAP NetWeaver XI tools.


2. You must configure source and target systems to automate the transfer of objects from SAP NetWeaver XI to CTS in source system export and to be able to control the import of objects into target systems using CTS.


3. To execute transports, use SAP NetWeaver XI tools for exporting objects in a transport request for CTS and CTS tools for performing transports.


End of Content Area

Transports Using the Change and Transport System (New)

Technical Data

Function is

New

For release

Software Component

Component: SAP NetWeaver

Release: 7.0

Support Package: 13

Assignment to application component

BC-CTS

BC-XI

Country Setting

Valid for all countries

Use

In this Support Package and higher, you can include the following SAP NetWeaver XI objects in one Change and Transport System (CTS) transport request and transport them together:

Integration Repository design objects

Integration Directory configuration objects

ABAP Mappings

This also enables you to use some of the advantages of CTS that were previously not supported when transporting SAP NetWeaver XI objects, for example the modeling of complex transport landscapes.

Tuesday, October 13, 2009

Concept of the Monitoring Architecture

Purpose

The alerts are displayed in a tree structure in the alert monitor, and assigned a severity and a color (yellow for a warning, red for a problem). You can see the current status of your system and process alerts here. The alert monitor is based on the monitoring architecture, which was introduced in SAP R/3 4.0:

This graphic is explained in the accompanying text

The CCMS monitoring architecture is not a monolithic monitoring and administration program. Rather, it offers a flexible framework into which extensive monitoring and administration functions can easily be added.

The elements of the monitoring architecture function largely independently of each other and can, particularly, be further developed and adjusted independently of each other.

· Data Supplier

A data supplier is a program that delivers data to the monitoring architecture. It belongs to one of the individual system components and creates monitoring objects that report values to the monitoring architecture. The monitoring architecture is delivered with the data suppliers for the most important components of your SAP system and its environment and can therefore be immediately used.

Data suppliers pass their information to the monitoring architecture. The monitoring architecture provides an infrastructure for gathering and managing system information. The monitoring architecture therefore constantly compares the values reported by the data suppliers for the monitored objects with threshold values and displays an alert if a value exceeds or falls below a threshold value.

· Data Consumers

A data consumer is a program that reads data from the monitoring architecture; it displays the information transferred to the monitoring architecture by the data suppliers. SAP delivers both the standard data consumer and other special monitors that all use the data delivered by the monitoring architecture.

· Monitoring Objects and Attributes

A monitoring object describes an object that is to be monitored. A monitoring attribute represents a type of information that is to be reported for a monitoring object. Monitoring objects include, for example, the CPU in your host system, the database, and SAP services, such as background processing. Monitoring attributes for a CPU object could be CPU utilization and the average CPU workload for the last five minutes.

The alert monitor also provides the administration methods that you need to monitor the system. In this way, you can set threshold values for alerts and add or adjust auto-reaction and analysis methods: if an alert is triggered, auto-reaction methods react automatically, and you can use an analysis method to investigate the cause of an alert without leaving the alert monitor. The monitoring architecture also contains tools for administering and archiving the alerts.

Leaving content frame

Data Transfer Using SAP XI

Purpose

You can realize cross-system business processes using the SAP Exchange Infrastructure (SAP XI). Within the overall architecture of SAP NetWeaver, SAP XI performs the tasks of process integration.

The integration of SAP XI and SAP BW allows you to use SAP XI to send data from various sources to the delta queue of SAP BW.

The integration of SAP XI and SAP BW offers the following advantages:

· Central maintenance of message flow between logical systems of your system landscape.

· Options for transformation of message content between sender and recipient

Mappings help you to adapt values and structures of your message to the recipient. In this way, you can transfer different types of files to a SAP BW system using interface mapping. However, in any case, it is necessary to transform the data into a format that corresponds to the interface of the function module that is generated in SAP BW and used for data transfer. The function module contains a table parameter with a flat structure. This means that the data have to be transformed so that they fit to a flat structure in SAP BW.

· Using proxy communication with SAP BW

Proxies are executable interfaces generated in the application systems for communication with the SAP XI Integration Server. We recommend the use of proxies for communication with SAP BW because they guarantee Full Quality of Service (Exactly Once in Order). They also guarantee that the data is delivered only once and in the correct sequence. The SAP XI Integration Server keeps the serialization as it was established by the sender.

Prerequisites

You are familiar with the concept, architecture and functions of SAP XI. You can find more information under SAP Exchange Infrastructure in the NetWeaver documentation.

You have integrated SAP BW and SAP XI. You can find more information on this in the configuration guide of SAP XI on the SAP Service Marketplace at the Internet address service.sap.com/instguides.

Process

...

1. Create a XML DataSource in SAP BW based on a file-data source. When you generate the DataSource, an RFC-capable function module is generated for data transfer. You can find more information under XML DataSource and Creating XML DataSources.

2. Activate the data transfer to the delta queue of SAP BW by initializing the delta process. You can find more information under Activating Data Transfer to the Delta Queue.

3. You create an inbound and an outbound message interface in the Integration Repository of SAP XI.

You can find more information under Design of Interfaces and Proxy Generation in the documentation for SAP XI.

If there is already an interface for data exchange in a system, you can import the interface description into the Integration Repository. You can find more information under Connection with Adapters and Imported Interfaces in the documentation for SAP XI.

The interface description in SAP BW is available in the form of the RFC-capable function module for the inbound message interface that was generated for your DataSource. To create the inbound message interface, you can import the function module into the SAP XI Integration Repository. You can find additional information under Import of Idocs and RFCs.

¡ If you are using an existing SAP XI scenario, the outbound message interface is already in the Integration Repository. Then you only need to create the inbound message interface.

¡ If you want to implement a new scenario, create an outbound message interface in addition to the inbound message interface.

4. You implement proxy generation for your inbound message interface in SAP BW.

An ABAP object interface (inbound or server proxy) is generated in SAP BW for the inbound message interface.

You can find more information under ABAP Proxy Generation in the documentation for SAP XI.


We recommend proxy communication with SAP BW because it guarantees Full Quality of Service (Exactly Once in Order).

5. You implement the generated ABAP object interface using an ABAP object class in SAP BW for recipient processing.

You can find more information under ABAP Proxy Objects in the documentation for SAP XI.

The proxy runtime calls this processing automatically after receiving the appropriate message.

Example

The document How to…Integrate BW to XI describes such an implementation. You can find the document on the SAP Service Marketplace at the Internet address service.sap.com/bw ® Services & Implementation ® HOW TO... Guides ® Guide List SAP BW 3.x.

6. If you have newly created the outbound message interface, you implement the data transfer according to your application case.

7. You implement the configurations in the Integration Directory of SAP XI that are relevant for message exchange. At the time of configuration, you set up the cross-system process for a concrete system landscape. The relevant objects are structure, organized and stored in the Integration Directory in the form of configuration objects.

You can find more information about the steps that you perform in SAP XI under Structure linkConfiguration and Structure linkDesign in the SAP XI documentation.

Result

You can now send data to the Integration Server of SAP XI, which transfers this data to SAP BW at runtime using proxy communication . In SAP BW, the data is written to the delta queue. From there, you can collect the data using the usual staging methods for deltas in SAP BW and then post it to the data targets.

The following graphic illustrates how the interface-based processing of messages works:

This graphic is explained in the accompanying text