![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
This two-part series introduces security and code management best practices for the IBM InfoSphere Information Server Pack for SAP Applications V7 (referred to hereafter as SAP Packs).
This first article introduces the relevant installation and security concepts and provides best practices for installing the required SAP side components and setting up security. The following topics are discussed in more detail:
- What needs to be done on the SAP side in order to use the SAP Packs.
- How to benefit from the authorization profiles for design time and run-time and how to customize them.
- Which SAP authorization requirements are needed for each stage (ABAP, IDoc, BAPI) in the different phases of the life cycle of a DataStage job.
The second article will describe the best practices for code management in real world, enterprise-level InfoSphere and SAP landscapes, including the following:
- Code management landscape for development, test and production systems.
- Simplified SAP side code management using CTS.
- Best practices for Information server-side code management requirements to align with the SAP-side code management.
- How to prevent code modifications in test and production systems.
IBM InfoSphere Information Server
IBM InfoSphere Information Server (see Resources) is a leading information integration platform. IBM InfoSphere Information Server provides a comprehensive set of capabilities to understand, cleanse, transform, and deliver trusted information for a broad variety of business scenarios such as master data management, business analytics and data warehousing, application migration and consolidation. IBM InfoSphere Information Server can be used as enterprise information integration platform for all data integration needs within an enterprise. It provides linear scalability, broad out-of-the-box connectivity to nearly all data sources, productivity tools for organizational efficiency and accelerated deployment, and a holistic metadata platform enabling end-to-end impact analysis and data lineage.
A core element of the IBM InfoSphere Information Server platform is a state of the art ETL component called DataStage. This component is used to rapidly develop UI-driven ETL jobs by drag & drop wiring of stages providing atomic operators such as sort, join, slowly changing dimensions, connectivity to a database and many more. The jobs can be created within folder structures within a development project. See Figure 1 for an example.
Figure 1. A DataStage project with an example job
Quick introduction to SAP Netweaver and interfaces
SAP provides many operational applications as well as business intelligence (BI) solutions based on its Netweaver platform (see Resources). SAP Netweaver ERP for enterprise resource planning, SAP Netweaver CRM for customer relationship management, SAP Netweaver SRM for supplier relationship management and SAP Netweaver SCM for supply chain management and SAP Netweaver BI are the most well-known operational applications and BI solutions from SAP. The operational applications are all built on a common Netweaver architecture as shown in Figure 2.
Figure 2. Netweaver – simplified architecture overview
The SAP Netweaver Web Application Server (SAP WebAS for short) is a common runtime infrastructure on which SAP customers can deploy their applications such as SAP Netweaver ERP. SAP Netweaver is implemented in ABAP, the SAP proprietary programming language. In recent years SAP also provides some functionality on a J2EE stack. The SAP WebAS of Netweaver is available in version 7.00 and newer. The root of this platform is the core runtime which was available as SAP WebAS in version 6.20 and version 6.40 on the SAP R/3 system already and is still in use at many enterprises today. Due to this history the IDoc, BAPI and ABAP (see Resources) application level interfaces exist since SAP R/3 and are still the most commonly used interfaces for data exchange between SAP systems as well as other systems in SAP Netweaver environments today. Notice that SAP Netweaver also offers web service interfaces – however for bulk data processing they are not suitable and thus not shown previously in Figure 2.
Exchanging data with SAP systems requires a bit of understanding on how the data architecture is designed. SAP applications have within the SAP WebAS the Data Dictionary (DDIC). The DDIC contains logical table definitions for all tables known by the SAP system. In addition, the SAP WebAS has the database abstraction layer (DB ASL). DDIC and DB ASL allow SAP to be independent of the underlying database, so SAP can support commercial database solutions such as Oracle, DB2 and Informix. To achieve this the DB ASL maps the logical table definitions to the physical model whenever database access is required.
An SAP business object such as customer, material, vendor or sales order usually spans multiple tables and the tables for a business object usually have parent-child relationships. However, since the database vendors have different implementations regarding primary key, foreign key relationships and other data integrity constraints, SAP is enforcing most of the data integrity constraints within the application and not in the database. As a consequence, it is not permitted to access the database used by an SAP application on database level with well-known interfaces such as JDBC or ODBC because only the SAP application knows about the relationship between the data tables and other data integrity constraints. A write operation to the database used by SAP might thus cause data integrity violations that in the worst case prevent the SAP application from working properly. This is the reason why data exchange with SAP always has to go through the SAP application level interfaces IDoc, BAPI and ABAP. Read operations do not share the same problem – however it is recommended to use the application-level interfaces also for read operations.
A short introduction to SAP Packs
The SAP Packs provide SAP certified connectivity to the SAP interfaces ABAP, BAPI and IDoc. They are part of a long list of connectors available for InfoSphere Information Server. InfoSphere Information Server is used with the SAP Packs in the following solution scenarios (example list only).
- SAP application consolidation and SAP business transformation: Improving data quality while reducing cost, risk and implementation time can be achieved for these scenarios with the Ready-To-Launch Solution. The Ready-To-Launch Solution is built on top of the Information Server and the SAP Packs (see Resources).
- Master Data Management solutions where master data is extracted from, or loaded to SAP applications.
- Enterprise Data Warehousing based on Netezza or InfoSphere Dynamic Warehousing solutions where SAP applications are part of the operational source systems.
- Any data integration project extracting data or loading data to SAP.
The following are two SAP Packs.
- InfoSphere Pack for SAP Applications: This pack provides support for the following interfaces ABAP, BAPI and IDoc with the following stages:
- ABAP Extract stage
- BAPI stage
- IDoc Extract stage and IDoc Load stage
- InfoSphere Pack for SAP BW:
- BW Extract stage and BW Load stage
Notice that the InfoSphere Pack for SAP BW provides access to the SAP Netweaver BI 7.x systems as well as the older SAP BW 3.x systems. However, for the remaining part of this article and the next, the InfoSphere Pack for SAP BW is not in scope.
The ABAP Extract stage provides a synchronous interface to SAP for data extraction purposes and has the following capabilities.
- Supports Extraction Object Builder and SQL Builder.
- Supports graphical construction of Open SQL queries.
- Loads and executes ABAP programs from DataStage.
- Supports ABAP syntax check ability in DataStage.
- Invocation of ABAP programs by DataStage.
- Supports RFC and FTP as data transfer methods.
An example job that uses the ABAP Extract stage is shown in Figure 3.
Figure 3. ABAP extraction job example
The architecture of the ABAP Extract stage can be split in a design-time part that covers the DataStage job development and a runtime part relevant for DataStage job execution (see Figure 4). It is critical to understand what is happening in each phase of the life cycle of the DataStage job because, as you will see later, the security authorization profiles reflect the different requirements and are thus separated along the same line.
Figure 4. ABAP design and runtime architecture
The developer uses the DataStage Designer to develop the jobs. The ABAP stage allows the developer to browse or search the DDIC to select the tables that he or she wants to extract data from by retrieving the required metadata from SAP. Joining tables is supported as well as refining the data scope by selecting only a subset of columns or defining a WHERE-clause. Once the data scope has been defined, the developer can trigger the ABAP code generation. An ABAP report is created based on the table metadata and specified SQL conditions which, if executed, reads the data from SAP and provides the data to DataStage for further processing. The custom ABAP report needs to be uploaded to SAP for which there are several procedures available.
- Using the ABAP stage UI.
- Using the ABAP stage UI by means of CTS (The SAP Change and Transport System).
- Manually by the SAP Basis Administrator.
Each of these options requires the technical SAP user to have specific
authorizations which will be discussed in more detail in stage-specific authorization details. If the
ABAP stage is configured to use the RFC data transfer method an RFC
destination must be set up on the SAP system to allow communication
between the ABAP report and DataStage. The RFC destination itself is
either manually created by the SAP Basis Administrator using
sm59 or by the ABAP stage at runtime if the
technical SAP user used by the job has the necessary authorizations to do
so.
At ABAP runtime, the previously configured DataStage job starts the execution of the ABAP program. The ABAP program returns the qualifying records to the DataStage job which can perform further processing steps and finally writes the data to the specified target such as a relational database.
The BAPI stage is based on the RFC protocol (see Resources) and provides synchronous access to the SAP system for the BAPI interface. The BAPI stage can be used to call the BAPIs available on the SAP system. The BAPI stage can also be used to invoke any Function Module (FM) which has been enabled for remote method invocation, so-called "Remote Function Modules" (RFM). RFMs are often build to provide custom access to SAP. For each BAPI or RFM, the developer can select which import, export and table parameters should be used in the job. An example BAPI job is shown in Figure 5.
Figure 5. BAPI job example
The architecture of the ABAP Extract stage can also be split in a design-time part that covers the DataStage job development and a runtime part relevant for DataStage job execution. Both are shown in Figure 6.
Figure 6. BAPI design and runtime architecture
At BAPI design time, the developer opens the BAPI stage and browses the list of all BAPIs and RFMs from the BAPI library with the BAPI explorer, possibly also using the provided filtering. Once the BAPI or RFM is found it is selected. Furthermore the developer selects the import, export and table parameters that he intends to use for the BAPI or RFM call and a choice is made if its used for inbound or outbound processing. With that information the BAPI or RFM can be invoked at runtime.
At BAPI runtime, the DataStage job with the BAPI stage synchronously invokes the BAPI or RFM configured using the RFC protocol. The input data is hereby provided by the input link whereas the output data is returned through the output link. This way BAPI stage can be used to load data to or extract data from the SAP system.
IDoc Extract and IDoc Load stage
The IDoc stages can be used to receive or send IDocs to, or from SAP, respectively. For extracting data from SAP using the IDoc Extract stage, the IDoc Listener Service on the DataStage Engine tier needs to be started. This component collects IDocs sent from SAP independent of which jobs are currently running. The jobs consuming these IDocs, as shown in Figure 7, and can be run manually, scheduled, or the IDoc Listener service can be configured to start them automatically after a certain amount of IDocs was received.
Figure 7. IDoc Extraction job example
When IDocs are loaded, as shown in Figure 8, the job will only receive a
status from SAP where SAP acknowledges the receipt of the IDoc. Depending
on the partner configuration this can mean that the IDoc itself is
processed asynchronously at a later time. In order to verify that SAP
actually processed the IDocs successfully the configuration must be
checked at a later point in time, which can be done using the SAP
transaction we02 or in case the Ready-to-Launch
Solution for SAP is used via post load reporting included in that
solution. Additional capabilities include setting the IDoc control record
values automatically before sending IDocs to SAP, as well as providing a
packet size for IDocs.
Figure 8. IDoc Load job example
The IDoc Extract stage and the IDoc Load stage share a common architecture regarding their design time used by developers at DataStage job development time and their runtime applicable to the DataStage job execution time. Both are shown in Figure 9.
Figure 9. IDoc design and runtime architecture
At IDoc design time, the developer opening the IDoc stage can browse the list of all IDocs in the SAP IDoc library and can retrieve the IDoc metadata. The developer chooses the IDoc and the IDoc version as well as the scope for the IDoc (not all segment tables in the segment table hierarchy of an IDoc are mandatory). The IDoc stages communicate with SAP using the RFC protocol. For IDoc processing the SAP Basis Administrator needs perform some SAP-side setup which includes configuring a gateway service, a RFC destination, a partner profile and a distribution model.
When running a DataStage job with an IDoc Load stage the job reads data from a data source, creates one or multiple instances of IDocs which are sent to SAP based on the asynchronous RFC protocol. SAP acknowledges the receipt of the IDoc but just places it into the IDoc inbound storage. Asynchronously at a later point in time SAP processes the IDocs and tries to write their content to the database used by SAP. Therefore, it needs to be checked after job completion whether or not SAP was able to successfully process all IDocs sent to it.
Before running a DataStage job with an IDoc Extract stage, the IDoc Listener needs to be started. If the IDoc Listener is running, then based on the configuration of the job, the job is either executed each time an IDoc is received from SAP or in bulk mode, in which case the IDoc listener accumulates the IDocs and starts a DataStage job after a certain amount of IDocs have been received.
Rapid Modeler for SAP and Rapid Generator for SAP
With SAP Packs version 7, two new capabilities have been added to the SAP Packs.
- Rapid Modeler for SAP allows to import logical tables and IDoc metadata from SAP into a data model of InfoSphere Data Architect.
- Rapid Generator for SAP allows to generate ABAP and IDoc jobs from those data models.
Both capabilities have been added to dramatically reduce the development time of ETL jobs reading or writing data to and from SAP. These capabilities are particularly valuable to develop batch ETL interfaces for SAP or in the context of SAP migration or consolidation projects using the Ready-to-Launch for SAP solution.
Figure 10 shows a logical data model created with the Rapid Modeler for SAP
in IBM InfoSphere Data Architect. The Data Project Explorer in the upper
left corner shows the logical data model
MATMAS04.ldm for the SAP IDoc type
MATMAS04. The main view shows two IDoc segments
of MATMAS04 and its corresponding IDoc
fields.
Based on this logical data model, a physical data model can be derived,
which is the base for the automatic DataStage job generation that is done
by the Rapid Generator for SAP. Figure 11 shows a fully generated
DataStage job with an IDoc Extract stage that processes
MATMAS04 IDocs and stores the IDoc segments in
a database.
Figure 10. Rapid Modeler – Extraction of SAP IDoc metadata into a logical data model
Figure 11. DataStage job generated by Rapid Generator
The SAP Administrator Client, as shown in Figure 12, is a tool that helps to configure the connections required by DataStage jobs using the SAP Packs. The SAP Administrator Client allows the creation and maintenance of SAP connections and additional configuration options like IDoc partner numbers.
Figure 12. DataStage Administrator Client for SAP
During a project where IBM InfoSphere Information Server is used for data exchange with SAP, a technical user on SAP needs to be made available for the DataStage jobs to connect to the SAP system. Therefore, a member from the ETL development team needs to work with the SAP Basis Administrator to get technical users for the SAP system with appropriate permissions. It is called a technical user because this user ID is supposedly only used by DataStage to connect to SAP, and these user IDs are supposedly not used to work through the SAP GUI with SAP.
A user in SAP is created by using the transaction
su01 as shown in Figure 13.
Figure 13. SAP transaction su01 for user maintenance
When creating a user, this is a client-specific operation since SAP is a multi-client system. This means that if DataStage needs to load data to SAP, then you need to know into which client identified by a 3-digit number the data should be loaded. Understanding the fact that SAP is a multi-client system is not only important for user management, it is also critical since importing transports to add custom functionality to SAP is also a client specific operation. As discussed in the installation section, when the deployment of the SAP Packs to SAP are explained, you need to know in which client you are installing.
When using su01 in the client for which either
data should be loaded or extracted, you can assign the expected parameters
like a user name, some description fields and a password for the user.
Another important concept of a user in SAP are authorization profiles as
shown in Figure 14.
Figure 14. Profiles for a user
A profile in SAP is the authorization to perform a certain task or a group
of tasks. For example, if you assign the SAP_ALL authorization to a user,
the user is permitted to do everything. If you only assign
B_ALE_ALL and S_IDOC_ALL, the user can perform ALL
operations and process IDocs, but can’t do other things. Using the
InfoSphere Packs for SAP requires depending on the stages you intend to
implement, and whether or not it is for design or runtime purposes or both
authorizations for the technical SAP user used. Those authorizations need
to be configured appropriately in su01 by the
SAP Basis Administrator for you.
SAP Packs authorization requirements
To perform the different steps of job design and job execution as described in the SAP Packs section, certain privileges must be granted to the technical SAP user. The privileges vary depending on the stage that is used and the phase in the life cycle of the DataStage job. There are pre-configured authorization profiles delivered with the product. For details on how to customize the authorization profiles see stage-specific authorization details.
An introduction to SAP Packs authorization profiles
There are two authorization profiles delivered with the product. The authorization profiles are made available as transport requests, so they can be imported into a SAP system as described in the Installation of the SAP Packs section.
An authorization profile is composed of authorizations. An authorization represents an authorization object together with the values that are assigned to the set of authorization fields that make up the authorization object.
The authorization profiles provided for the SAP Packs are composed of SAP-defined authorizations when possible, but also contain authorizations specifically configured for the use with the SAP Packs. In addition, SAP provides complete pre-defined authorization profiles that contain all authorizations needed to perform a specific set of activities, for example S_IDOC_ALL contains all the authorizations needed for working with IDocs. When available these SAP-defined profiles are documented for the use with the SAP Packs.
The delivered authorization profiles contain the required authorizations needed for using the ABAP, BAPI, and IDoc stages. In addition to these profiles, the technical SAP user must have the following SAP-defined profiles assigned to use the full SAP Packs functionality.
- S_IDOC_ALL and B_ALE_ALL to access IDoc stage functionality.
- Each BAPI / RFM call has its specific authorization requirements.
- S_TMW_CREATE to access ABAP Extract stage Change and Transport System (CTS) functionality.
The user is required to have a developer key assigned when using CTS to upload the ABAP program.
The two authorization profiles delivered with the product are called Z-DS_LOAD and Z_DS_PROFILE. Z-DS_LOAD is the design-time profile that contains all authorizations needed to create and run SAP Packs jobs. Z_DS_PROFILE is the runtime profile that contains only the authorizations needed to run SAP Packs jobs. This distinction is made to provide users with an authorization profile that can be used in a development environment (Z-DS_LOAD) where tasks like job design and unit-testing are performed and one that is more restrictive and can be used in a production environment (Z_DS_PROFILE) where only activities needed during the actual job run should be allowed.
Mapping of the SAP authorizations to development, test and production environments
A detailed discussion on best practices using the authorization profiles in relation to different environment strategies is covered in more detail in the second article. The focus of this section is on the required SAP privileges for the different environments which is described for a basic environment setup with a development, testing and production environment.
On the development system, DataStage jobs are designed and unit-tested. To perform these tasks, the technical SAP user needs design-time as well as runtime privileges for the stages that are to be used in the jobs to be developed.
The testing environment should simulate the production environment. On this system, the technical SAP user should be assigned only the runtime authorizations needed for the stages used in jobs that are to run in the production environment.
In the production environment there are usually the most restrictive security policies established. As a result, only the absolutely necessary privileges should be granted to the technical SAP user, which means only the runtime authorizations needed for the stages used in the jobs running in production.
Detailed information on the different authorizations needed for each stage type at design and runtime are found in the stage-specific authorization details section, and enable customizations of the authorization profiles for the different environments.
Stage-specific authorization details
The following section contains specific information on authorizations needed for each stage depending on the respective phase in the life cycle of the DataStage job. This information will help to customize authorization profiles according to your needs. For details on the different activities that are performed for each stage, see the SAP Packs section. The following is an overview list of the different usage scenarios described in this section.
- ABAP Extract stage
- ABAP stage using RFC (job design)
- ABAP stage using RFC (job run)
- ABAP stage using FTP (job design)
- ABAP stage using FTP (job run)
- ABAP stage using background processing for the ABAP program
- ABAP stage using CTS for uploading the ABAP program
- BAPI stage
- Job design
- Job run
- IDoc stages
- Job design
- Job run
- Rapid Modeler for SAP
- Table metadata
- IDoc metadata
Use SAP transaction SU02 to create an
authorization profile or to adjust the imported authorization profiles.
ABAP stage authorizations using RFC (job design) are shown in Table 1.
Table 1. ABAP stage authorizations using RFC (job design)
| Authorization Object | Authorization Class | Description | Authorization Definition |
|---|---|---|---|
| S_RFC | AAAB | Authorization check for RFC Access | ACTVT: 16 RFC_NAME: SYST, SDTX, SDIFRUNTIME, RFC1, SALF, ZETL, ZETL_CTS RFC_TYPE: FUGR |
| S_DEVELOP | BC_C | ABAP Workbench | ACTVT: 01, 02, 03, 06, 16 DEVCLASS: * OBJTYPE: PROG OBJNAME: * P_GROUP: * |
| S_TABU_DIS | BC_A | Table Maintenance | ACTVT: 03 DISBERCLS: * |
| S_RFC_ADM | AAAB | Administration for RFC Destination | ACTVT: 03 ICF_VALUE: * RFCDEST: * RFCTYPE: T |
Notes:
- S_DEVELOP: You can adjust OBJNAME according to the naming convention that you want to use for ABAP programs generated by the ABAP stage (for example specify Z_DS* instead of *).
- S_RFC_ADM: You can adjust RFCDEST according to the naming conventions that you want to use for the RFC destinations used for communication with the ABAP stage.
ABAP stage authorizations using RFC (job run) are shown in Table 2.
Table 2. ABAP stage authorizations using RFC (job run)
| Authorization Object | Authorization Class | Description | Authorization Definition |
|---|---|---|---|
| S_RFC | AAAB | Authorization check for RFC Access | ACTVT: 16 RFC_NAME: SYST, SDIFRUNTIME, RFC1, SALF, QOWK, ZETL, ZETL_CTS RFC_TYPE: FUGR |
| S_RFC_ADM | AAAB | Administration for RFC Destination | ACTVT: 01, 03, 06 ICF_VALUE: * RFCDEST: * RFCTYPE: T |
| S_DEVELOP | BC_C | ABAP Workbench | ACTVT: 03, 16 DEVCLASS: * OBJTYPE: PROG OBJNAME: * P_GROUP: * |
| S_ADMI_FCD | BC_A | System Authorizations | S_ADMI_FCD: NADM |
| S_BTCH_JOB | BC_A | Background Processing | JOB_ACTION: RELE JOBGROUP: * |
Notes:
- S_DEVELOP: You can adjust OBJNAME according to the naming convention that you want to use for ABAP programs generated by the ABAP stage (for example specify Z_DS* instead of *)
- S_RFC_ADM: This authorization is only needed if you enable automatic creation and deletion of the RFC destination in the ABAP stage. You can adjust RFCDEST according to the naming conventions that you want to use for the RFC destinations used for communication with the ABAP stage.
ABAP stage authorizations using FTP (job design) are shown in Table 3.
Table 3. ABAP stage authorizations using FTP (job design)
| Authorization Object | Authorization Class | Description | Authorization Definition |
|---|---|---|---|
| S_RFC | AAAB | Authorization check for RFC Access | ACTVT: 16 RFC_NAME: SYST, SDTX, SDIFRUNTIME, RFC1, ZETL, ZETL_CTS RFC_TYPE: FUGR |
| S_DEVELOP | BC_C | ABAP Workbench | ACTVT: 01, 02, 03, 06, 16 DEVCLASS: * OBJTYPE: PROG OBJNAME: * P_GROUP: * |
| S_TABU_DIS | BC_A | Table Maintenance | ACTVT: 03 DISBERCLS: * |
Note: S_DEVELOP: You can adjust OBJNAME according to the naming convention that you want to use for ABAP programs generated by the ABAP stage (for example specify Z_DS* instead of *).
ABAP stage authorizations using FTP (job run) are shown in Table 4.
Table 4. ABAP stage authorizations using FTP (job run)
| Authorization Object | Authorization Class | Description | Authorization Definition |
|---|---|---|---|
| S_RFC | AAAB | Authorization check for RFC Access | ACTVT: 16 RFC_NAME: SYST, SDIFRUNTIME, RFC1, ZETL, ZETL_CTS RFC_TYPE: FUGR |
| S_DEVELOP | BC_C | ABAP Workbench | ACTVT: 03, 16 DEVCLASS: * OBJTYPE: PROG OBJNAME: * P_GROUP: * |
| S_BTCH_JOB | BC_A | Background Processing | JOB_ACTION: RELE JOBGROUP: * |
| S_DATASET | BC_A | Authorizations for file access | ACTVT: 34 FILENAME: * PROGRAM: Z*,Y* |
Note: S_DEVELOP: You can adjust OBJNAME according to the naming convention that you want to use for ABAP programs generated by the ABAP stage (for example specify Z_DS* instead of *).
ABAP stage authorizations for background job processing are shown in Table
5.
Add the following authorizations to your ABAP stage runtime
profile if you want to run the ABAP program that extracts the data, as a
background job in your SAP System.
Table 5. ABAP stage authorizations for background processing of the ABAP program
| Authorization Object | Authorization Class | Description | Authorization Definition |
|---|---|---|---|
| S_RFC | AAAB | Authorization check for RFC Access | ACTVT: 16 RFC_NAME: SXMI, SXBP RFC_TYPE: FUGR |
| S_XMI_PROD | BC_A | Authorizations for external management tool | INTERFACE: XBP EXTPROD: DATASTAGE EXTCOMPANY: IBM Corp. |
ABAP stage authorizations for CTS support.
Assign the following SAP-defined authorization profile to the user that
configures the ABAP jobs (design-time user): S_TMW_CREATE
This profile grants the required authorizations to add the ABAP
program by means of a transport request to your SAP System. In addition
the user must have a developer key assigned to create transport requests.
Authorizations for BAPI stage (job design) are shown in Table 6.
Table 6. Authorizations for BAPI stage (job design)
| Authorization Object | Authorization Class | Description | Authorization Definition |
|---|---|---|---|
| S_RFC | AAAB | Authorization check for RFC Access | ACTVT: 16 RFC_NAME: SYST, SDIFRUNTIME, RFC1, SEM5, SWOR RFC_TYPE: FUGR |
Authorizations for BAPI stage (job run) are shown in Table 7.
Table 7. Authorizations for BAPI stage (job run)
| Authorization Object | Authorization Class | Description | Authorization Definition |
|---|---|---|---|
| S_RFC | AAAB | Authorization check for RFC Access | ACTVT: 16 RFC_NAME: SYST, BAPT RFC_TYPE: FUGR |
Each BAPI call has its specific authorization requirements. For more information about the required authorizations, see the BAPI documentation.
Authorizations for IDoc stages (job design) are shown in Table 8.
Table 8. Authorizations for IDoc stages (job design)
| Authorization Object | Authorization Class | Description | Authorization Definition |
|---|---|---|---|
| S_RFC | AAAB | Authorization check for RFC Access | ACTVT: 16 RFC_NAME: SYST, SDIFRUNTIME, SDTX, RFC1, EDIMEXT RFC_TYPE: FUGR |
| S_TABU_DIS | BC_A | Table Maintenance | ACTVT: 03 DISBERCLS: * |
In addition assign the SAP-defined authorization profile to the user performing the IDoc job configuration: S_IDOC_ALL.
Authorizations for IDoc stages (job run) are shown in Table 9.
Table 9. Authorizations for IDoc stages (job run)
| Authorization Object | Authorization Class | Description | Authorization Definition |
|---|---|---|---|
| S_RFC | AAAB | Authorization check for RFC Access | ACTVT: 16 RFC_NAME: SYST, SDIFRUNTIME, RFC1, EDIN RFC_TYPE: FUGR |
In addition assign the SAP-defined authorization profile to the user running the jobs: B_ALE_ALL.
Authorizations for extracting table metadata are shown in Table 10.
Table 10. Authorizations for extracting table metadata
| Authorization Object | Authorization Class | Description | Authorization Definition |
|---|---|---|---|
| S_RFC | AAAB | Authorization check for RFC Access | ACTVT: 16 RFC_NAME: RFC1, SDIFRUNTIME, SDTB, SDTX, SYST RFC_TYPE: FUGR |
| S_TABU_DIS | BC_A | Table Maintenance | ACTVT: 03 DISBERCLS: * |
Authorizations for extracting IDoc metadata are shown in Table 11.
Table 11. Authorizations for extracting IDoc metadata
| Authorization Object | Authorization Class | Description | Authorization Definition |
|---|---|---|---|
| S_RFC | AAAB | Authorization check for RFC Access | ACTVT: 16 RFC_NAME: SYST, SDIFRUNTIME, SDTX, RFC1, EDIMEXT RFC_TYPE: FUGR |
| S_TABU_DIS | BC_A | Table Maintenance | ACTVT: 03 DISBERCLS: * |
In addition assign the SAP-defined authorization profile to the user
performing the IDoc job configuration: S_IDOC_ALL.
For running the generated ABAP and IDoc jobs find the required ABAP
and IDoc runtime authorizations shown previously.
Changes in the security authorization profiles
This section describes the changes in the security authorization profiles from version 6.5.x.x to version 7.0.
SAP Authorizations contained in Z_DS_PROFILE and related changes are shown in Table 12.
Table 12. SAP authorizations contained in Z_DS_PROFILE
| Authorization Object | Description | Authorization | Changes since v6.5.x.x |
|---|---|---|---|
| S_RFC_ADM | Administration for RFC destinations | Z:DS_RFC_ADM | |
| S_RFC | Authorization check for RFC access | Z:DS_RFC | |
| S_DATASET | Authorization for file access | Z:DS_DATASET | |
| S_CPIC | Calls from ABAP programs | Z:DS_CPIC | |
| S_TABU_DIS | Table Maintenance | Z:DS_TABU_DI | |
| S_BTCH_JOB | Background processing | Z:DS_BJOB | |
| S_XMI_PROD | Authorization for external management interfaces | Z:DS_XMI | |
| S_ADMI_FCD | System authorizations | Z:DS_ADMIFCD | added for the ABAP Extract stage in v7 |
| S_DEVELOP | ABAP Workbench | Z:DS_RUN |
SAP Authorizations contained in Z-DS_LOAD and related changes are shown in Table 13.
Table 13. SAP authorizations contained in Z-DS_LOAD
| Authorization Object | Description | Authorization | Changes since v6.5.x.x |
|---|---|---|---|
| S_RFC_ADM | Administration for RFC destinations | Z:DS_RFC_ADM | |
| S_RFC | Authorization check for RFC access | Z:DS_RFC | |
| S_DATASET | Authorization for file access | Z:DS_DATASET | |
| S_CPIC | Calls from ABAP programs | Z:DS_CPIC | |
| S_TABU_DIS | Table Maintenance | Z:DS_TABU_DI | |
| S_BTCH_JOB | Background processing | Z:DS_BJOB | |
| S_XMI_PROD | Authorization for external management interfaces | Z:DS_XMI | |
| S_ADMI_FCD | System authorizations | Z:DS_ADMIFCD | added for the ABAP Extract stage in v7 |
| S_DEVELOP | ABAP Workbench | Z:DS_LOAD | |
| S_CTS_ADMIN | Administration functions in CTS | Z:DS_CTS_AD | |
| S_TRANSPRT | Transport Organizer | Z:DS_TRANSP |
For the installation of the SAP Packs the following three main parts are installed.
- Server-side installation where the InfoSphere Information Server components are installed.
- Client-side installation where the InfoSphere Information Server clients are installed.
- Installation of SAP Transports on the SAP application systems.
The first two parts are not in the scope of this article (see Resources). The following section focuses on the components that must be deployed on the SAP side to use the SAP Packs. The SAP Transport Management System works per client, so the deployment needs to be performed for each SAP client that is supposed to be used with the SAP Packs.
For illustrating the best practices example, a SAP Netweaver ERP 6.0 Unicode system on AIX is used. In Tables 14 and 15 you find the transport IDs for other system combinations.
Table 14. Transport IDs for other system combinations - Unicode
| Unicode | ||
|---|---|---|
| ECC 6.0 | R/3 | |
| RFC Service | R47K900478 | R47K900478 |
| RFC Service CTS | R47K900485 | R47K900485 |
| Authorization Profiles | RP5K900874 | R47K900498 |
Table 15. Transport IDs for other system combinations - non-Unicode
| non-Unicode | ||
|---|---|---|
| ECC 6.0 | R/3 | |
| RFC Service | EC1K900176 | E47K900252 |
| RFC Service CTS | EC1K900177 | E47K900256 |
| Authorization Profiles | EC1K900182 | E47K900257 |
There are 3 transports delivered with the product that need to be imported to SAP. Each transport consists of 2 files, a data and a co-file.
- RFC Service IIS Pack for V7.0 consists of: R900478.R47 and K900478.R47
- RFC Service (CTS) IIS Pack for V7.0 Unicode consists of: R900485.R47 and K900485.R47
- Profiles for IIS Pack for SAP V7.0 (ECC 6.0, Unicode) consists of: R900874.RP5 and K900874.RP5
Table 16 shows you the detailed content of each transport.
Table 16. Content per transport
| Transport ID | Description | Content |
|---|---|---|
| K900478.R47 | RFC Service IIS Pack for SAP 7.0 (Unicode) | Function Modules: Z_DS_ABAP_TRANS, Z_RFC_DS_SERVICE Database Tables: ZETLTRSF, ZETLTRSFX Structures: ZETLSTR |
| K900485.R47 | RFC Service (CTS) IIS Pack for SAP 7.0 (Unicode) | Function Modules: Z_RFC_DS_SERVICE_CTS |
| K900874.RP5 | Profiles for IIS Pack 7.0 (ECC 6.0, Unicode) | Authorization Profiles: Z-DS_LOAD, Z_DS_PROFILE |
To prepare the transports for the import in the SAP client copy the data
and co-files to the respective sub-directories. The files named
Rxxx are the data files and must be copied to
the data sub-directory in the transport directory, and the files named
Kxxx are the co-files and must be copied to the
co-files sub-directory in the transport directory of your SAP
installation. This leads to the following file listings for the 2
directories (also shown in Figure 15).
Data Directory (in our example located in /usr/sap/trans/data).
- R900478.R47
- R900485.R47
- R900874.RP5
Co-files Directory (in our example located in /usr/sap/trans/cofiles).
- K900478.R47
- K900485.R47
- K900874.RP5
Figure 15. Example location for the transports on AIX
Make sure the files are owned by root and have the 777 file permission. Otherwise you might get an error message during the deployment of the transports.
Note: If you want to make use of CTS for deploying the required SAP-side
components to your system landscape, then you have to create the packages
ZETL and ZETL_CTS with the appropriate transport route definition for your
environment before you continue to import the transports that you just
added to your file system. Work with your SAP Administrator to get the
correct transport layer for your environment. You can use transaction
se80 to create a new package. In Part 2 of this
article series you will find detailed information on deployment
strategies.
- To get started deploying the transports, log in to your SAP system.
Open the SAP transaction STMS (short for SAP Transport Management
System) as shown in Figure 16.
Figure 16. Starting the STMS transaction for deploying ABAP Transports
- Click on the truck icon shown in Figure 17.
Figure 17. Start screen of Transport Management System
- The screen shown in Figure 18 shows where all your import queues are
listed. Double-click the queue which you intend to use for your
transports, which is usually the SID of the SAP system.
Figure 18. List of import queues for transports
- In order to add the SAP Packs transports to your input queue, go to
Extras – Other Requests –
Add, as shown in Figure 19.
Figure 19. Start to add a transport to a transport queue
- Select the SAP Packs transport you want to import, as shown in Figure
20. Repeat this for each of the SAP Packs transports.
Figure 20. List of available transports to be added
- As a result the three transports are added to the imports queue as
shown in Figure 21.
Figure 21. List of imports
- Now you have the following two choices. You can either import each transport individually by clicking the truck icon where the back part of the truck is partially covered in yellow, or you can import all transports together by clicking the truck icon where the back part of the truck is fully covered in yellow as shown in Figure 21. Note: Make sure you import the RFC Service transport (R47K900478) before the RFC Service (CTS) transport (R47K900485).
- Once you've triggered the import, a pop-up screen appears as shown in
Figure 22.
Figure 22. Select the client
- Enter the client number for which you intend to install the SAP Packs.
SAP is a multi-client system, so you need to install the SAP Packs in
each client where you want to use it. Also select the option
Immediate in case you want to get the transports
applied right away. Then click on the green check mark on the lower
right corner of the pop-up moving you to the screen shown in Figure 23
where you need to confirm the import request.
Figure 23. Confirm import request
This completes the SAP Packs installation including the installation of the security profiles. In case you want to check if the imports were successful, you can check the logs by right-clicking on the transport request and selecting Logs from the list. Furthermore you can verify that the RFC services and authorization profiles are available on the system.
Open se80 and select the package ZETL for the RFC service and ZETL_CTS for the CTS RFC service respectively. Now you can verify if the components listed in the previous table are in place as shown with the example in Figures 24 and 25.
Figure 24. Function Builder
Figure 25. DataStage Administrator Client for SAP
Open su01 again and try to assign the Z_DS_PROFILE and Z-DS_LOAD security authorization profiles to a user as shown in Figure 26.
Figure 26. Assigning the design and run-time authorizations for SAP Packs to a technical SAP user
In this article InfoSphere Information Server and InfoSphere Information Server Pack for SAP Applications V7 were introduced. The article discussed the authorization requirements for each of the SAP Packs stages as well as for the Rapid Modeler and Generator for SAP. It also provided details on which authorizations are needed in the different phases of the DataStage job life cycle. With this information you can customize the authorizations according to the requirements in the respective system environment where you want to use the SAP Packs.
Part 2 of this article series will provide you with the best practices on how to apply the security concepts and authorization profiles for addressing different security and code management requirements in enterprise-level Information Server and SAP environments.
The authors would like to thank their colleague Oliver Suhre for his valuable feedback and comments improving this article.
Learn
- Use an RSS feed to request notification for the upcoming articles in
this series. (Find out more about RSS feeds of
developerWorks content.)
- Review the A Matter of Time: Temporal Data Management in DB2 for z/OS
article.
- Find out more about the InfoSphere Information Server.
- Learn more about the developerWorks InfoSphere Information Server Best Practices
Series.
- Read the Information Server Deployment Topologies developerWorks article.
- Visit the InfoSphere Information Server v8.7 Information Center.
- Visit the IBM InfoSphere Information Server Pack for SAP Applications
Information Center.
- Read the Driving successful business transformation White Paper for
information on the Ready-To-Launch Solution for SAP.
- Learn more about SAP Netweaver.
- Stay current with developerWorks technical events and webcasts focused on a variety
of IBM products and IT industry topics.
- Attend a free
developerWorks Live! briefing to get up-to-speed quickly on IBM
products and tools as well as IT industry trends.
- Follow developerWorks on
Twitter.
- Watch developerWorks on-demand demos ranging from product installation
and setup demos for beginners, to advanced functionality for experienced
developers.
Get products and technologies
-
Evaluate IBM
products in the way that suits you best: Download a product trial,
try a product online, use a product in a cloud environment, or spend a few
hours in the SOA Sandbox learning how to implement Service Oriented
Architecture efficiently.
Discuss
- Participate in the discussion forum.
- Get involved in the My developerWorks
community. Connect with other developerWorks users while exploring
the developer-driven blogs, forums, groups, and wikis.
Christian Gaege is a software engineer working in the Information Platform and Solutions team. He started at IBM in 2008 in the IBM Silicon Valley Labs in the United States and is currently based in the IBM Research and Development Lab in Germany. Christian is developing applications and tools for the integration of SAP into the IBM Information Server product portfolio. He holds a master's degree in computer science from Furtwangen University in Germany.
Martin Oberhofer works as Senior IT Architect in the area of Enterprise Information Architecture with large clients world-wide. He helps customers to define their Enterprise Information Strategy and Architecture solving information-intense business problems. His areas of expertise include master data management based on an SOA, data warehousing, information integration and database technologies. He especially likes to work with enterprises running SAP applications solving the SAP-specific information management challenges. Martin provides, in a lab advocate role, expert advice for Information Management to large IBM clients. He started his career at IBM in the IBM Silicon Valley Labs in the United States at the beginning of 2002 and is currently based in the IBM Research and Development Lab in Germany. Martin co-authored the books Enterprise Master Data Management: An SOA Approach to Managing Core Information and The Art of Enterprise Information Architecture: A Systems-Based Approach for Unlocking Business Insight as well as numerous research articles and developerWorks articles. As inventor, he contributed to over 30 patent applications for IBM. Martin is also a The Open Group Master Certified IT Architect and holds a master’s degree in mathematics from the University of Constance/Germany.
Nicole Schoen is a software engineer working in the Information Platform and Solutions team at the IBM Research and Development Lab in Boeblingen. She started working for IBM as a developer for OMEGAMON XE for DB2 Performance Expert on z/OS in 2006. Now she is developing applications and tools for the integration of SAP into the IBM Information Server product portfolio.
Table of contents
Next steps from IBM
WebSphere Portal can help your small and midsize business achieve better website security, along with faster time to value with easily deployable and customizable example Web sites.
- Try: Download a free trial version of IBM WebSphere Portal Express V6.1, which offers collaboration, document management, and secure Web content management.
- Article: This article provides an overview of the WebSphere Portal security architecture, including internet security, and secure connections between clients.
- Tutorial: This tutorial take you through the steps to develop and test your first portlet WebSphere Portal Test Environment.
- Demo: These demos show Web 2.0 features available today within WebSphere Portal, as well as several features planned for the future.
- Buy: IBM WebSphere Portal Express
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
