Tbit40 en Col95 Fv Part a4

(1)

TBIT40

SAP NetWeaver Process

Integration

SAP NetWeaver Process Integration

Date Training Center Instructors Education Website

Participant Handbook

Course Version: 95

Course Duration: 5 Days Material Number: 50102747

An SAP course - use it to learn, reference it for work

For internal u s e by C S C only For internal u s e by C S C only

(2)

Copyright

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice.

Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.

Trademarks

• Microsoft®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint® and SQL Server® are registered trademarks of Microsoft Corporation.

• IBM®, DB2®, OS/2®, DB2/6000®, Parallel Sysplex®, MVS/ESA®, RS/6000®, AIX®, S/390®, AS/400®, OS/390®, and OS/400® are registered trademarks of IBM Corporation. • ORACLE® is a registered trademark of ORACLE Corporation.

• INFORMIX®-OnLine for SAP and INFORMIX® Dynamic ServerTM are registered trademarks of Informix Software Incorporated.

• UNIX®, X/Open®, OSF/1®, and Motif® are registered trademarks of the Open Group. • Citrix®, the Citrix logo, ICA®, Program Neighborhood®, MetaFrame®, WinFrame®,

VideoFrame®, MultiWin® and other Citrix product names referenced herein are trademarks of Citrix Systems, Inc.

• HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology.

• JAVA® is a registered trademark of Sun Microsystems, Inc.

• JAVASCRIPT® is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.

• SAP, SAP Logo, R/2, RIVA, R/3, SAP ArchiveLink, SAP Business Workflow, WebFlow, SAP EarlyWatch, BAPI, SAPPHIRE, Management Cockpit, mySAP.com Logo and mySAP.com are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other products mentioned are trademarks or registered trademarks of their respective companies.

Disclaimer

THESE MATERIALS ARE PROVIDED BY SAP ON AN "AS IS" BASIS, AND SAP EXPRESSLY DISCLAIMS ANY AND ALL WARRANTIES, EXPRESS OR APPLIED, INCLUDING

WITHOUT LIMITATION WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, WITH RESPECT TO THESE MATERIALS AND THE SERVICE, INFORMATION, TEXT, GRAPHICS, LINKS, OR ANY OTHER MATERIALS AND PRODUCTS CONTAINED HEREIN. IN NO EVENT SHALL SAP BE LIABLE FOR ANY DIRECT,

INDIRECT, SPECIAL, INCIDENTAL, CONSEQUENTIAL, OR PUNITIVE DAMAGES OF ANY KIND WHATSOEVER, INCLUDING WITHOUT LIMITATION LOST REVENUES OR LOST PROFITS, WHICH MAY RESULT FROM THE USE OF THESE MATERIALS OR INCLUDED SOFTWARE COMPONENTS. For internal u s e by C S C only For internal u s e by C S C only

(3)

About This Handbook

This handbook is intended to complement the instructor-led presentation of this course, and serve as a source of reference. It is not suitable for self-study.

Typographic Conventions

American English is the standard used in this handbook. The following typographic conventions are also used.

Type Style Description

Example text Words or characters that appear on the screen. These include field names, screen titles, pushbuttons as well as menu names, paths, and options.

Also used for cross-references to other documentation both internal and external.

Example text Emphasized words or phrases in body text, titles of graphics, and tables

EXAMPLE TEXT Names of elements in the system. These include report names, program names, transaction codes, table names, and individual key words of a programming language, when surrounded by body text, for example SELECT and INCLUDE.

Example text Screen output. This includes file and directory names and their paths, messages, names of variables and parameters, and passages of the source text of a program.

Example text Exact user entry. These are words and characters that you enter in the system exactly as they appear in the documentation.

<Example text> Variable user entry. Pointed brackets indicate that you replace these words and characters with appropriate entries. For internal u s e by C S C only For internal u s e by C S C only

(4)

About This Handbook TBIT40

Icons in Body Text

The following icons are used in this handbook.

Icon Meaning

For more information, tips, or background

Note or further explanation of previous point Exception or caution

Procedures

Indicates that the item is displayed in the instructor's presentation. For internal u s e by C S C only For internal u s e by C S C only

(5)

Process Integration and Web Services or Enterprise Services 355 B2B: Business-to-Business...368 Unit 6: Business Process Management ... 375 ccBPM Overview: Integration Processes ...376 ccBPM: Designing and Configuring Integration Processes ....383 Unit 7: Appendixes ... 403 Case Study ...404 Appendix: Configuring the Proxy Runtime ... 411 Appendix: Overview of ALE Configuration in SAP_BACKEND 417 Appendix: SAP Gateway: Registering External Programs ...423 Glossary... 431 For internal u s e by C S C only For internal u s e by C S C only

(7)

Course Overview

This course demonstrates how to implement scenarios in a distributed system landscape using SAP NetWeaver Process Integration. It introduces the architecture and features of SAP NetWeaver Process Integration. It gives a detailed introduction to scenario configuration and the connection of back-end systems using adapters.

Target Audience

This course is intended for the following audiences:

• Developers and consultants who want to configure scenarios using SAP NetWeaver Process Integration

Course Prerequisites

Required Knowledge

• Basic knowledge of business processes in distributed system landscapes • Basic knowledge of integration technologies

Recommended Knowledge • basic understanding about XML

Course Goals

This course will prepare you to:

• Configure scenarios in SAP NetWeaver Process Integration (PI) • Connect systems to SAP NetWeaver PI using adapters

Course Objectives

After completing this course, you will be able to: • Configure synchronous and asynchonous scenarios

• Connect sending or receiving SAP systems using various adapters

• Use the file adapter both to transfer files as a data source to SAP NetWeaver Process Integration and to write messages from SAP NetWeaver Process Integration to a file

SAP Software Component Information

The information in this course pertains to the following SAP Software Components and releases: For internal u s e by C S C only For internal u s e by C S C only

(8)

Course Overview TBIT40

• SAP NetWeaver Process Integration 7.3

(9)

Unit 1

Introduction to SAP NetWeaver

Process Integration

Unit Overview

This unit introduces the functions and architecture of SAP NetWeaver Process Integration.

Unit Objectives

After completing this unit, you will be able to:

• Describe how SAP NetWeaver Process Integration processes messages • List the options available for connecting application systems to SAP

NetWeaver Process Integration

Unit Contents

Lesson: Overview of SAP NetWeaver Process Integration Architecture and Features ...2

Exercise 1: Determine the Software Components Installed in the Course System... 13 For internal u s e by C S C only For internal u s e by C S C only

(10)

Unit 1: Introduction to SAP NetWeaver Process Integration TBIT40

Lesson: Overview of SAP NetWeaver Process Integration

Architecture and Features

Lesson Overview

This lesson explains how SAP NetWeaver Process Integration (SAP PI) processes messages and you can connect application systems.

Lesson Objectives

After completing this lesson, you will be able to:

Business Example

You want to implement business processes in a distributed system landscape. You want messages to be sent as uniformly as possible when data is transferred between systems. You want to use SAP NetWeaver Process Integration to do this.

SAP NetWeaver Process Integration basics

The prerequisite to this lesson is basic knowledge of SAP NetWeaver Process Integration, so the following topics are a brief summary.

Architecture and tools of SAP NetWeaver Process Integration SAP NetWeaver Process Integration comprises various components, and an additional installation option

(11)

TBIT40 Lesson: Overview of SAP NetWeaver Process Integration Architecture and Features

Figure 1: Architecture of SAP NetWeaver Process Integration

• System Landscape Directory (SLD) contains information about the Landscape (Technical Systems and Business Systems) and the Software Catalog (Product and Software Component Versions). You can configure an SAP System to register itself in the SLD.

• Enterprise Services Repository contains design objects like interfaces, mappings, process definitions.

• Services Registry is a UDDI complaint registry, listing available Web Service Definitions (based on WSDL), extended with a classification system. • Integration Directory is used to configure the scenarios for the message

exchange.

• Business Process Engine controls message correlations and how messages are processed as part of cross component Business Process Management (ccBPM).

• Integration Engine of the Integration Server processes messages in the Integration Directory according to the configuration. This involves determining the receiver and mapping the inbound message to the receiver interface structure.

• Advanced Adapter Engine provides the basis for many adapters used to connect systems to the Integration Server.

• Runtime Workbench is a tool used for central monitoring of components and messages.

The following graphic explains the tools that you use to access the PI components.

(12)

Figure 2: PI UI tools to access the components

• SAP NetWeaver Developer Studio (NWDS) is the eclipse-based Java Development tool of SAP, and can be used to view and edit some object types in Enterprise Services Repository.

• Enterprise Services Builder provides the Java user interface (GUI) you use when working in Enterprise Services Repository.

• Integration Builder provides the Java user interface (GUI) you use when working in the Integration Directory, and also regulates versioning and lock management on the server.

• SAPGUI is the client tool to acess the ABAP stack of PI.

Implementing the System Landscape in the Sys-tem Landscape Directory

Technical Systems: you enter all the Technical Systems of the customer-specific system landscape in the SLD. This includes host names and other technical attributes, as well as information about the software components that are installed on a server.

Note: The structure of the SLD is based on the Common Information Model (CIM) standard. CIM was developed by the Distributed

Management Task Force (DMTF), a consortium, which aims to organize the administration of IT systems in distributed landscapes.

(13)

Business Systems represent sender and/or receiver systems of messages. You assign a Business System name to each technical system in SLD. For ABAP systems, you assign a business system to each client that shall exchange messages with PI. Business systems are then imported into the Integration Directory.

Figure 3: Mapping the System Landscape in the System Landscape Directory

Interfaces and Mapping Programs in Enterprise Services Repository

In addition to the technical and the assigned business systems, the products and their software components and versions, which run on the technical systems, are also created in the SLD. These software components are imported into Enterprise Services Repository. Within the software component version, you create the namespaces in which you then store the interface objects that you use in your business processes.

Interface objects include the inbound and outbound interfaces themselves, details for mapping, and so on.

The uniqueness of an object in Enterprise Services Repository is determined by the following three elements: the name of the object, the name of the software component and the associated namespace.

(14)

Figure 4: Mapping Software Component Versions and Their Interfaces You can import interfaces into Enterprise Services Repository (RFC, IDoc, XSD/WSDL definitions), or you can also create them manually in Enterprise Services Repository.

You define outbound and inbound interfaces in Enterprise Services Repository. If the outbound and inbound messages in a scenario do not match up, then you also define mapping rules for a structure mapping in Enterprise Services Repository. For this purpose, you are provided with a graphical mapping tool, or you can create mapping programs in Java, ABAP or XSLT. In addition to the structure mapping, which maps the source and inbound structures to each other, you can also define a value mapping, which maps values of the structure to the required values in the inbound structure. (Example: value 001 in the Material group field to value abc in Material group)

(15)

Figure 5: Mapping Interfaces and Defining Mappings

Enterprise Services Repository allows you to define the relationships between interfaces and business processes in a transparent way. To do so, you create an integration scenario, which represents the relationships between interfaces in an abstract form (without the assignment of specific systems).

Figure 6: Implementing a Scenario and Assigning the Interfaces and Mappings Used

You can create process steps (referred to as actions) for a system with a particular role. You can assign outbound and inbound interfaces to each of these actions. You can connect the actions with connecting lines. You can represent synchronous and asynchronous connections. Select an outbound interface for the sender system

(16)

action and an inbound interface for the receiver system action for each connection. You can specify a mapping program, if necessary, which maps the outbound interface to the inbound interface.

Hint: Integration scenarios and objects referenced in those scenarios (such as interfaces and mappings), are also provided by SAP (and partners) as ESR content / XI content. They can be used as configuration templates and, in this way, they simplify the implementation of standard scenarios. Configuring Scenarios in the Integration Directory

Enterprise Services Repository only stores information relating to the development objects of a software component. For these objects it is not important whether and on which server the software component is actually installed.

To allow business processes to actually run in a distributed system landscape, you need the configuration objects that you store in the Integration Directory.

Figure 7: Configuring Scenarios in the System Landscape in the Integration

Directory

In addition to the sender and receiver (as services) and the adapters, the following configuration objects also belong to the configuration in the Integration Directory:

(17)

Figure 8: Configuration Objects in the Integration Directory

The messages can be processed by the Integration Engine (pipeline processing), or by the Advanced Adapter Engine (AAE), depending on the required adapters and functionality.

For processing by the Integration Engine, you configure how the sender technically links up with PI (Sender Agreement), and the receiver to which a message is to be sent (Receiver Determination). Further on, you configure which inbound interface receives the message for the receiver (Interface Determination), and how the Integration Server can technically link up with the receiver system (Receiver Agreement).

For processing by the Advanced Adapter Engine, you create an Integrated Configuration, and maintain the routing information therein.

In addition, the Integration Directory provides an object in which you can bundle all the configuration objects that belong together, namely: the configuration scenario. Configuration scenarios make it easier to use configuration objects. Connecting Application Systems to SAP NetWeaver

Process Integration

The Integration Engine of SAP NetWeaver Process Integration expects to receive an inbound message in a specific PI XML format, and sends messages in this PI XML format to the receiver systems. To connect systems, the following question

(18)

must first be answered: Can the sender system create the message to be sent in PI XML format, and can the receiver system make sense of a message in PI XML format?

A local Integration Engine is part of SAP Basis release 6.20 and later, and this local Integration Engine can directly exchange message with SAP NetWeaver PI based on the PI XML format. The application system uses PI proxies for the message exchange.

Figure 9: Runtime Procedure: Conversion to PI Message Format Using adapters is the other connectivity option for SAP NetWeaver PI. The connected system provides data in its format and the adapter converts between that format and PI XML format, and transfers it to PI message processing.

SAP technical adapters are included with SAP NetWeaver Process Integration, but you can also use adapters from SAP partners.

(19)

Runtime Procedure of SAP NetWeaver PI pipeline processing

Figure 10: Runtime Procedure: Pipeline

Processing begins in the Integration Server pipeline as soon as a message reaches the Integration Server in PI message format. Firstly, the receiver and the receiver inbound interface are determined from the configuration data. This step is called logical routing. If there are multiple receivers, the message is duplicated. For each receiver, the message with the structure of the sender outbound interface is mapped to the structure of the receiver inbound interface. The pipeline then determines the technical method for contacting the receiver. This is called technical routing. Finally, the message is sent to the target system or corresponding adapter.

The Role of SAP NetWeaver Process Integration 7.3 as

a Central Infrastructure for SOA

SAP NetWeaver Process Integration 7.3 has two different potential utilizations: • The architecture of SAP NetWeaver PI 7.3 is based on an established

architecture for implementing cross-system business processes, and represents an enhancement of earlier releases.

• SAP NetWeaver PI plays a key role in supporting a service-oriented architecture for business applications (SOA). The focus here is on a service-based integration of applications.

(20)

SOA supports the basic principles of a service-oriented architecture (messaging structure, tools for creating services, tools for consuming services, registry and repository tools, and so on), but it does not provide an additional business logic. SAP provides an infrastructure as well as executable content in the form of enterprise services, which encapsulate the relevant functions of the Business Suite.

Figure 11: Building Blocks of SOA

In an application that uses enterprise services, SAP NetWeaver Process Integration acts as an Enterprise Service Bus (ESB) at runtime to facilitate the exchange of calls between the various services.

Interfaces are centrally stored in the Enterprise Services Repository.

Hint: SAP NetWaver Process Integration as well as SAP NetWeaver Composition Environment use the Enterprise Services Repository.

(21)

Exercise 1: Determine the Software

Components Installed in the Course

System

Exercise Objectives

After completing this exercise, you will be able to:

• Determine installed software components and their versions in SAP systems

Business Example

You want to create clarity within your enterprise as to which versions of which software components are installed in the systems.

Task:

Determine which software component versions are installed in the available systems.

1. Determine the software components installed in the NetWeaver Process Integration system of the current course.

System-ID is RWN, client 800.

2. Determine the software components installed in the SAP back-end system of the current course.

System-ID is RWE, client 800.

(22)

Solution 1: Determine the Software

Components Installed in the Course

System

Task:

Determine which software component versions are installed in the available systems.

1. Determine the software components installed in the NetWeaver Process Integration system of the current course.

System-ID is RWN, client 800.

a) Log on to the SAP NetWeaver Process Integration system that is to be used for the course.

b) Choose System → Status.

c) Under SAP System Data, choose Component Information.

Here you will find the software components installed and their versions.

Hint: Please note that the software component PI_BASIS is Plug-In Basis. PI does not mean Process Integration here. 2. Determine the software components installed in the SAP back-end system

of the current course.

System-ID is RWE, client 800.

a) Log on to the SAP back-end system that is to be used for the course. b) Choose System → Status.

c) Under SAP System Data, choose Component Information.

Here you will find the software components installed and their versions.

(23)

Lesson Summary

You should now be able to:

(24)

Unit Summary TBIT40

Unit Summary

You should now be able to:

(25)

(26)

(27)

Unit 2

The System Landscape

Unit Overview

The technical system landscape determines the basic technical conditions for an integration solution. To achieve a successful integration, it is therefore important that you analyze your system landscape first.

• Which servers are available?

• Which basis software is installed on which server? (AS ABAP, AS Java, and so on.)

• Which application software is installed on which server? Which external interfaces and services are provided by the application software?

This unit explains how you can map your system landscape in the System Landscape Directory (SLD) of SAP NetWeaver Process Integration. It also covers how you define information for software components that are installed on the systems. You will be shown how to transfer software components from the SLD into the Enterprise Services Repository, and which information needs to be added in the Enterprise Services Repository. You will also be shown how to transfer systems entered in the SLD into the Integration Directory and how to enhance them by using communication channels.

Unit Objectives

After completing this unit, you will be able to:

• Display SAP products and software components in the SLD

• Display software components in the Repository and check for interfaces • Manually create products and software components in the SLD

• Display technical systems in the SLD and check their attributes • Describe how SAP systems can register with the SLD

• Manually create a technical system in the SLD and assign products and software components

• Create a business system in the SLD and assign it to a technical system • Import a business system into the Integration Directory

(28)

Unit 2: The System Landscape TBIT40

Unit Contents

Lesson: Design Objects in the SLD and Enterprise Services Repository 19 Exercise 2: Check Software Components and Products... 43 Lesson: Implementing Technical Systems... 49 Exercise 3: Create Technical Systems in SLD ... 55 Lesson: Business Systems in the SLD and the Integration Directory .... 60 Exercise 4: Create and Import Business Systems ... 69 Exercise 5: Create a communication channel using a template ... 75

(29)

TBIT40 Lesson: Design Objects in the SLD and Enterprise Services Repository

Lesson: Design Objects in the SLD and Enterprise

Services Repository

Lesson Overview

This lesson shows how to map software components in the System Landscape Directory, how to import them into Enterprise Services Repository, and specifies the interface objects that can then be created within the software component version.

Lesson Objectives

After completing this lesson, you will be able to:

• Display SAP products and software components in the SLD

• Display software components in the Repository and check for interfaces • Manually create products and software components in the SLD

Business Example

Your integration scenario is based on a system landscape that consists of multiple servers and on which software is installed. Essential information relating to these software components is required by SAP NetWeaver Process Integration, and must be stored centrally in a System Landscape Directory. This lesson covers how software components can be mapped, how they can be integrated into Enterprise Services Repository, and which interface objects can be created within the software component versions.

Software Components and Products: Definition of

Terms

From a software vendor's point of view, a software component is a modular entity that you can implement in multiple products. A product contains independent software components. Software components are subject to further development, which results in various software component versions.

A product is a grouping of software components that is shipped to customers. A product is also subject to further development. This might be due to new changes made to the software components that it contains, or due to the addition of further software components if the product has had functional enhancements made to it. Thus, most of the time each product has multiple product versions. For example, the product SAP Customer Relationship Management (SAP CRM) has the product versions SAP CRM 4.0, 5.0, 7.0 and more.

In an ABAP system, one or more software components are assigned to a product. The software components may, in turn, have various software component versions.

(30)

Product versions are software units that can be installed on your system and that run independently of other software (for example, SAP ERP 6.0).

Figure 12: Products and Software Components

In the SLD, the relationship between the product version and the software component versions is represented by an independent object known as a software feature. This enables you to represent complex products. In contrast to the products and software components (versions) that are visible in the SLD, the software features are not based on any visible objects.

Hint: You can access the SLD in various ways. In an ABAP back-end, you may use transaction SLDHTMLGUI to connect to the SLD.

Displaying Products and Software Components in the

SLD

To display the products and software components along with their versions in the System Landscape Directory, choose Software Catalog from the SLD initial screen.

(31)

Figure 13: Example of a Product and a Software Component

You can import SAP products and SAP software components into the SLD. Your administrator does after PI installation. The latest updates are also provided on the SAP Service Marketplace and should be imported twice a year.

If you use non-SAP software components and products, you need to manually create these in the SLD.

External Interfaces of Software Components

Each software component provides programs for particular functions. Software components have external interfaces to enable them to communicate with other software components. These can be both inbound and outbound interfaces.

(32)

Figure 14: Software Component with External Interfaces Examples of SAP inbound interfaces are:

• BAPIs and remote-enabled function modules (RFMs) in general • File interfaces

• Inbound IDoc interfaces

• XML interfaces (SAP Basis 6.20 or higher)

• Java or ABAP inbound proxies (SAP Basis 6.20 or higher) • Web Services

• Enterprise Services

Outbound interfaces cannot all be described by one object; they exist implicitly. Examples of SAP outbound interfaces include the following:

• File interfaces in the form of a program that creates a file • IDoc outbound interfaces

• RFC outbound interfaces in the form of a program that starts a remote function call by using CALL FUNCTION...DESTINATION

• XML interfaces in the form of a program that sends an XML message by using HTTP

• Java or ABAP outbound proxies (SAP Basis 6.20 or higher) • PI outbound proxies For internal u s e by C S C only For internal u s e by C S C only

(33)

Software Components and Interface in Enterprise

Services Repository

Detailed information about the external interfaces of a software component is stored in Enterprise Services Repository within the software component version. In Enterprise Services Repository, you first have to import the software

components from the SLD. You then create the Namespaces in the software component version, and use the namespace for the interfaces.

A namespace semantically groups objects, in a similar way to ABAP packages (previously called development classes) or to Java packages. Namespaces must be globally unique, and not just for software components; they make interface objects uniquely identifiable.

The following conventions can be useful for creating namespaces: • Prefix http://

When you specify an HTTP address as a namespace this does not mean that you can access additional information about the namespace from this address (in some cases an XML schema definition is hidden behind the address). The HTTP address used merely ensures that the name of the namespace is unique. SAP namespaces follow the standard http://sap.com/xi/.

• Prefix urn:

Namespaces with these types of prefix have no value in the sense that they are not connected with a Web page in the Internet.

Caution: It is assumed that conventions ensure that namespaces are unique. For more information about namespaces, go to www.w3.org/TR/REC-xml-names/.

Within a namespace, the Enterprise Services Builder allows you to maintain objects in different areas. These include Process Integration scenario objects, modeling objects in the Enterprise Services area, interface objects, mapping objects and adapter objects, as well as objects that identify a work area, in other words, software components and namespaces.

The key objects of an interface (in the interface objects area) are service interfaces, together with the corresponding service operations, message types, and data types.

(34)

Figure 15: SLD Interface for Enterprise Services Repository

Service Interfaces and Their Subcomponents

SAP NW PI provides content with the interfaces of enterprise services for Enterprise Services Repository. You can also define new interfaces for enterprise services in the Enterprise Services Builder.

Data types are the basic components of interfaces. Data types define simple or complex XML data structures, which can be created in a data type editor or imported.

With SAP NW PI, you determine the structure of data types based on their classification. There are three types of data type:

• Freely-modeled data types • Core data types

• Aggregated data types

SAP uses core data types and aggregated data types to create the signature of enterprise services.

The modeling of core data types (CDT) and aggregated data types is based on the UN/CEFACT Core Component Technical Specification, or CCTS for short (see also ISO 15000-5). This methodology formulated by the UN/CEFACT Committee defines semantic modules (core component types) independently of syntax, which take account of the current requirements for the generic description of business data. The implementation of this methodology facilitates, in particular,

(35)

the realization of cross-company processes. In SAP, a CDT defines a “primary component” (also referred to as a “content component”) and one or more optional “supplementary components”. The character of a CDT is defined using a “representation term” (for example, “Amount”). Unlike Free-Style data types, core data types also contain additional information about the semantics of a data type. SAP currently identifies 25 representation terms for core data types (for example, Amount, Text, Identifier, Date, Time, Name, Description).

Caution: The representation term of a core data type defines semantics for a more accurate characterization of the data type, but does not yet define business-relevant semantics with a specific reference to business processes. For example, the characterization of a data type with the “Amount” representation term indicates directly that the value of this type must also be specified more precisely with a currency. This type of mandatory characterization does not apply to free modeling of this category of data type as an XSD type (for example, xsd:decimal). The actual business semantics are contained in the Global Data Types (GDT). Global Data Types are based on CDTs, and are used across SAP as a basis for application-specific data types. However, in contrast to last category of data type described above, they are not intended for a specific usage. On the contrary, a GDT is designed to be reused later in many different application scenarios. These data types are therefore rather “broad”, and need to be refined when they come to be used in a specific application. CDTs themselves are not application-specific, and are therefore also described as “context-free”. SAP creates a GDT as a core data type or aggregated data type in Enterprise Services Repository. This depends on whether the CDT merely enhances a CDT with business semantics, or whether CDTs (and any aggregated data types that may already exist) are used in a new, aggregated data type.

Note that all data types contained in your Repository PI 7.0 or lower are classified as Free-Style data types in the upgrade.

Hint: ES Repository was named Integration Repository in older PI releases.

Freely-modeled data types include elementary data types, which define the properties of elementary fields. Several fields can be grouped together in a complex data type to describe the structure of an XML document node. Elements belonging to a complex data type can be typed with an elementary XML type, an elementary data type, or with a complex data type. This allows you to construct nested data types. An occurrence is specified for each element. In SAP NW PI 7.0 and lower, a complex data type was created for the structure of the document

(36)

as a whole. The fields of this structure reference complex data types, which correspond to line types. The number of occurrences of the node permitted at runtime (cardinality) is also determined.

Hint: The term node here is used to mean a structure.

The message type describes the structure of a message that was either sent or received by SAP NetWeaver Process Integration, and determines the root element of the message. It references a single, complex data type. A message type can be used for both outbound and inbound service interfaces.

An XSD version of the message type is provided in Enterprise Services Repository for the export of the interface.

In contrast to the message interfaces in SAP PI 7.0 and lower, you use a service interface to describe operations that you need for a subsequent implementation in the application system, independently of a platform or programming language.

Figure 16: Service Interface and Service Operation

Note: With SAP NetWeaver PI 7.3, you can create some interface objects in the SAP NetWeaver Developer Studio. You can create service interfaces, data types, and message types using the Enterprise Services Browser view. New for this version is that you can activate or reject changes of a pending change just in SAP NetWeaver Developer Studio.

(37)

A service interface therefore serves as a structured element, and contains one or more service operations. The service operations, in turn, reference one or more message types (request/response in the case of synchronous operations), and thus also the description of the inbound or outbound messages. A service operation represents the service interface and its interface as a whole, uses attributes to describe the type of interface used, and distinguishes between inbound and outbound interfaces. If the interface is used in an integration process, then it becomes an interface with the attribute abstract, this attribute has no direction (outgoing or inbound) but represents the placeholder of the message in the integration process.

You can define Fault Message Types for application error messages and reference them in synchronous interfaces.

Hint: Asynchronous inbound interfaces can also reference a fault message type, in which case the application error persists in the target system.

Figure 17: Enterprise Services Repository: Service Interface, Service Operation, Message Type, and Data Types

Example: Interface with a Nested Structure

These interface objects are presented in a specific sample scenario below.

(38)

Figure 18: Data Type and Message Type

The following objects have been created in Enterprise Services Repository for the SC_BIT400_A software component:

A service interface and service operation of the outbound and asynchronous type references the MT_Material message type A message type MT_Material that references the nested data type DT_Material

An elementary data type DT_MaterialID

A simply structured data type DT_MaterialDescription that contains the two string-like fields Language and Description

A nested data type that contains required entry fields as well as an optional field and a structured element defined using the data type DT_MaterialDescription. This structured element is optional since the attribute MinOccurs = 0; the number of occurrences is not restricted since the attribute MaxOccurs = unbounded.

At runtime, the corresponding message might look as an XML document:

(39)

Figure 19: XML Structure of the Source Document

Example: Message with Multiple Nodes

The receiver inbound interface in the example scenario consists of a message with two independent node types. Each node is optional and can have an unlimited number of occurrences at runtime. The term node here means structure in an XML document.

Figure 20: Message Type with Multiple Nodes

(40)

Figure 21: XML Structure of the Target Document

The interface is available as a WSDL file for exporting interfaces. In the WSDL file messages types become message elements, data types become type elements and the interface itself becomes a port element.

Figure 22: Interface Objects and WSDL

Context objects are a particular element within the interface definitions. Imagine a message InvoiceOut that, among other things, contains the address of a customer.

For example, you would use the following expression in XPath to access the contents of a field such as postalCode, which is stored in the address of customerData and which belongs to the InvoiceOut message:

(41)

/InvoiceOut/customerData/address/postalCode. If you need this expression in several conditions, then you must type it or copy it in every time. Alternatively you can assign a context object to the postalCode field, for example with the name PostalCode. In all conditions where you need the field value, it is enough to use PostalCode from the context object, so that these conditions are more readable.

Figure 23: Context Objects in Enterprise Services Repository and Their Assignment

Context objects encapsulate the XPath expression with which you would otherwise access the field contents and they represent a comfortable alternative to XPath expressions for accessing message contents.

Hint: The context object is used for typical key fields and has a business-related/meaningful name. You can reference a context object in several interfaces to clarify which different interface fields correspond to the same business content.

After you have created a context object in Enterprise Services Repository and assigned it to the field of a request message (Context Object tab page in the service interface), you can use it in the following situations:

1. To determine the receiver of a message depending on its content. 2. To process the process steps depending on the content of a message.

(42)

There is a range of predefined technical context objects to enable you to access the message header information.

How Interfaces Are Entered in Enterprise Services

Repository

All interfaces involved in the message flow of the scenarios should be stored in the ES Repository. This way, the interface can easily be chosen using the input help during configuration. Further on, the interfaces can easily be referenced during the creation of scenarios or mapping. Finally, the ES Repository acts a central point of information for all interfaces.

How do you maintain interfaces in Enterprise Services Repository?

Figure 24: Interfaces in Enterprise Services Repository

(43)

You can create interfaces using one of the following methods:

• Service interface and service operation: You create these interfaces in Enterprise Services Repository with the Enterprise Services Builder or the SAP NetWeaver Developer Studio.

• External definitions: You can import interfaces with structures that have been defined using WSDL, XSD, or DTD, into Enterprise Services Repository.

• Imported (SAP) objects: You can import RFC signatures and IDoc types from an SAP system by RFC. In doing so, you generate an XML schema. In this case, connection data to an SAP system that contains the current RFC signatures or IDoc types is defined for the software component.

Note: SAP does only deliver some IDoc types and RFC signatures of their Software Components in the ES Repository.

Caution: If you intend to import an SAP IDoc type or RFC signature, you should import it into your customer specific Software Component Version.

(44)

Figure 25: SAP Interfaces in Enterprise Services Repository

Hint: For problems with IDoc or RFC imports, see SAP Notes 677732 (Authorizations), 672745 (Missing Function Modules), 212011 (Access to IDoc Metadata) and 718320.

ES Repository as part of SAP NetWeaver CE and SAP

NetWeaver PI

Enterprise Services Repository (ES Repository) is delivered as part of SAP NetWeaver Composition Environment (CE) and SAP NetWeaver Process Integration (PI). If you have an installation of SAP NetWeaver CE and PI in your system landscape, SAP strongly recommends that you maintain all your design objects in a single ES Repository.

(45)

Figure 26: ES Repository for CE and PI

You use this procedure to set up either the SAP NetWeaver CE or PI ES Repository as the central repository in your landscape. Depending on the scenario, you can run a wizard, which automatically disables one repository and reconfigures the other as the central repository. You can run this wizard only from the SAP NetWeaver Administrator on CE

If you want to configure the CE ES Repository as your central repository, the wizard performs the following steps:

• Disables the ES Repository on PI • Connects the ES Repository on CE

• Creates the PI service and content users on the CE system • Performs post configuration checks

(46)

When you want to configure the PI ES Repository as the central ES Repository, the wizard performs the following steps:

• Disables the ES Repository on CE • Connects the ES Repository on PI

• Removes PI service and content users from CE system • Performs post configuration checks

Note: SAP NetWeaver Process Integration has a tight coupling with ES Repository and requires configuration to connect to a given ES Repository. By default, SAP NetWeaver Process Integration connects to the default ES Repository delivered with it, while SAP NetWeaver CE can connect to any ES Repository in the landscape. Hence, until enhancement package 1 of SAP NetWeaver CE 7.1, we recommended to use the ES Repository delivered with SAP NetWeaver Process Integration as the central ES Repository in your landscape.

However, as of SAP NetWeaver CE 7.2, SAP provides the capability to automatically reconfigure your SAP NetWeaver Process Integration to connect to the latest ES Repository in the landscape. So if you have an installation of SAP NetWeaver CE 7.2 or above version, we recommend to use the latest version of ES Repository in the landscape.

Enterprise Services Repository Web UI

Apart from the ES Builder, you can also access the contents of the ES Repository by using the Web-browser view. This view enables you to access objects in the repository in a Web browser, without launching the ES Builder.

Figure 27: Web UI access to Enterprise Services Repository

(47)

You use the Web browser to:

• View interface objects in the ES Repository

Note: You can view only active objects. If an object is in your change list, the last saved version is available.

You cannot create objects in the Web browser. • Manage subscriptions

You can subscribe, unsubscribe, and edit your subscriptions • Manage lifecycle of objects

You can change the values of custom attribute of type Lifecycle. For example, change the lifecycle of a service interface from In Progress to Review.

Note: As a prerequisite for the Web UI, you need Internet Explorer 7.0 or higher

Enterprise Services Objects Access

Enterprise Services Repository is a development environment where vast numbers of users achieve different goals based on their requirements. It represents not only the central access point for users to develop services, but also access to the development of cross-component processes based on the exchange of XML messages. Since the ES Repository caters to a variety of users, it contains numerous models and design time objects. However, only a small subset of these objects may be of interest to different user groups. The ES Repository provides the functionality to adapt the environment to your needs. Depending on the goals you wish to pursue, you can have a different subset of objects from the ES Repository, which helps to reduce the complexity of the tool. The following tools help you to filter and search on objects:

Usage Profile

The usage profile defines the set of object types, software component versions, and business modeling filters that you can use. They are personalized filters that enable you to view and work with only a set of object types, software component versions, and modeling filters required to achieve your goals. All the other object types are hidden.

In the ES Builder, you can choose from a set of predefined usage profiles delivered by SAP. However, if they do not meet your requirements, then you can create your own usage profile.

(48)

Based on the common usage of various user groups or roles, SAP delivers three predefined usage profiles. You can choose from the following standard usage profiles available in the ES Builder:

1. Service Development

This basic selection facilitates modeling and interface development. 2. Process Integration

This basic selection facilitates the modeling of cross-component processes and the development of interfaces and mappings, as well as adapter objects. 3. Unrestricted

This basic selection contains the total amount of object types of both of the Service Development and Process Integration usage profiles.

When you log on to the ES Builder for the first time you can choose a usage profile based on your requirements. However, you can always change this selection later in the ES Builder. For internal u s e by C S C only For internal u s e by C S C only

(49)

The following areas of ES are affected based on usage profile restrictions: • Navigation Path

The navigation path only displays the object types defined by the usage profile.

• Create Dialog

The create dialog only displays the object types that are editable. • Object Editor

The restricted object types and software component versions are displayed in the object editor pane only when you navigate to them via references or other means. However, you can only view these objects and they are not edit them. • Deep Copy

A deep copy cannot create or overwrite objects restricted by usage profiles. In such cases, these object types are excluded.

• Search and F4 Help Dialog

You can only view the software component versions and object types defined by the active usage type using the search and F4 help dialog.

• Source Object for Cross Reference

Cross referenced objects are displayed in the read-only mode. • Export and Release Transfer

If you select single objects for Export and Release Transfer, then you can specify only from the editable objects available. However, if you select a software component version for export, all the object types (including the hidden object types) will be exported. For release transfer, you can choose the target software component version only if it is not hidden.

Context Perspective

The context perspective in the ES Builder provides improved access to objects, better navigation capabilities, and allows you to work with a subset of objects of your choice. For internal u s e by C S C only For internal u s e by C S C only

(50)

In this view, you can perform the same set of operations as with the classic view. You can use this perspective to:

• Access recently used objects

To access objects that you recently created, edited, and viewed, expand the Work Context node under My Workplace

• Create folders based on filter criteria

• Access information from multiple user interfaces on one user interface To view the referenced objects and where-used list for a specific object, select an object from My Workplace or My Work History and expand the References node.

To view the properties of an object, select an object from My Workplace or My Work History and expand the Properties node.

To switch to the design objects, change list or conflicts tab page, choose the required option from the tool bar on the left.

To locate the opened object in the navigation tree of My Workplace, choose the Link Work Context with Editor icon.

• Run applications using widgets

To run specific applications that suit your needs, click ES Repository Widgets, and choose Add or Customize Widgets and select the required widget. Based on the action you want to perform, proceed as follows:

To access objects that you recently created, edited, and viewed, expand the Work Context node under My Workplace.

To define a folder based on specific filter criteria, such as software component version, namespace, object type, or object name, perform the following steps: 1. Select the Search Folders node under My Workplace

2. From the context menu, choose New Search Folder 3. Enter a name for the search folder

4. If you want to filter objects based on object names, enter the object name in the Object Filter field

5. Select the required software component versions and namespaces on which you want to define search filters

6. For the software component versions and namespaces selected in the above step, select the corresponding object types on which you want to define search filters

7. Choose Create.

To view the referenced objects and where-used list for a specific object, select an object from My Workplace or My Work History and expand the References node.

(51)

To run specific applications that suit your needs, perform the following steps: a. Click ES Repository Widgets

b. Choose Add or Customize Widgets and select the required widget: Search Objects by Documentation:

Once you browse for services in the ES Workplace, you can then search for the required objects based on the documentation in the ES Workplace. You use this feature to search for objects in the ES Repository to ensure reuse. You can search for an object by transferring the documentation URL from the ES Workplace. Log on to the ES Builder.

Choose Perspective , Select Perspective, Context Click ES Repository Widgets.

Choose Add or Customize Widgets and select Search by Documentation To search for an object in the ES Repository, drag and drop or paste a documentation link from ES Workplace to the assigned area on the widget. Managing Subscriptions

1. Subscribe

In the Enterprise Services Builder, you subscribe to an interface object if you want to receive e-mails of changes made to the object. You receive notifications when an interface object is modified or deleted. For service interfaces, you can also choose to receive notifications when you classify or publish a service interface. Use this procedure to subscribe and unsubscribe to notifications

In the context menu of an interface object, choose Manage Subscription. The New Subscription dialog box appears.

In the Notification Event section, select the events for which you want to receive notifications.

To receive an e-mail notification, specify a valid e-mail address Choose OK.

2. Unsubscribe

Choose Perspective, Select Perspective, Context Click ES Repository Widgets.

Choose Add or Customize Widgets and select My Subscriptions.

Select the subscription you want to unsubscribe and in the context menu, choose Unsubscribe. Confirm the pop-up.

Note: “Context Perspective”, “Search based on documentation”, and “Subscribing for objects” are new features for SAP NetWeaver 7.3

(52)

Unit 2: The System Landscape TBIT40 For internal u s e by C S C only For internal u s e by C S C only

(53)

Exercise 2: Check Software Components

and Products

Exercise Objectives

After completing this exercise, you will be able to: • Check component information in the SLD

• Display software components and their interfaces in ES Repository

Business Example

You want to use standard interfaces from software components for an

integrated scenario. A representation of the most important software component characteristics and their corresponding interfaces is a prerequisite for this.

Task 1: Component Information in the System

Landscape Directory

Check the component information in the System Landscape Directory (SLD). 1. Log on to the SLD.

2. Is the SAP APO product in the SLD? How many product versions are there? Which software components belong to product version 3.1? Use the Products link on the initial screen of the SLD in the Software Catalog node.

3. For the purposes of this course, we have created products and software components that are not delivered. Which software component versions does the Product_BIT400 product have?

Task 2:

In Enterprise Services Repository, search for the interfaces configured for software components SC_BIT400_A Version 1.0, SC_BIT400_B Version 1.0, and SAP APPL 6.03.

1. Log on to Enterprise Services Repository. Use your user from the Integration Server.

Continued on next page

(54)

2. Search for the software components listed above. Check which interfaces have been saved for each of these software components. Note the different types of interface, namely, service interfaces that have been created, SAP interfaces that have been imported (IDocs, RFCs), and external interfaces. 3. Take a closer look at the SI_Material_outb service interface of the

SC_BIT400_A software component. You see that a service operation with the same name is assigned to this component. A message type is, in turn, assigned to the service operation. Navigate to the message type. How many nodes does it have? Are there any optional nodes? Are there nodes that can have multiple occurrences in the message? Which data types are referenced? 4. Take a closer look at the SI_Materials_inb service operation in the

SI_Materials_inb service interface of the SC_BIT400_B software component: Navigate to the message type. How many nodes does the message type have? Are there any optional nodes? Are there nodes that can have multiple occurrences in the message? Which data types are referenced?