Developing Business Logic

Purpose

You first define a collaborative process independent of a particular system landscape and create design objects in the Integration Builder.

The proxy programming specifies how you implement proxies so that applications can communicate with the Integration Server.

Process Flow

..

1. For descriptions of the design objects integration scenario, integration process, interface, and mapping, see Design.

2. You use the proxy programming to implement the communication of an application with the Integration Server by means of the proxy runtime. See also: Proxy Runtime

3. For more information about how to use the Integration Builder and the functions it provides, see Integration Builder.

4. For information about the versioning of design objects and how they are transported, see Software Logistics for XI Objects.

Developing Business Logic Design

Purpose

The development of a collaborative process begins with its design (see: Design Time). The Integration Builder provides you with an environment with which you can describe integration scenarios, integration processes, interfaces, and mappings independently of a system landscape. These objects are stored in the Integration Repository and are associated with software component versions that belong to a product that is to be shipped (see: Software Logistics for XI Objects).

Prerequisites

Software component versions are the smallest shipment units that can be shipped using the objects of the Integration Repository. To be able to develop within a software component version, they must be maintained in the software catalog of the System Landscape Directories (SLD). SAP products and the corresponding software component versions are already maintained in the SLD. It is also possible to include external products and software component (versions) in the SLD (see: Software Catalog).

Process Flow

The following steps are usually carried out in the design phase:

...

1. To save objects in the Integration Repository, you import the software component versions in which the objects are developed (see: Importing Software Component Versions). The development manager normally has the authorization required for this.

2. To document the business process on a more abstract level, create an integration scenario. This is regardless of whether integration process, interface, or mapping objects already exist or not. If objects are available, you can reference them directly. If not, you can create the objects from the integration scenario. An Integration scenario is the key for understanding the entire process (see: Designing Integration Scenarios).

3. To define the contents of a message and the communication type, create new message interfaces in the Integration Builder or import existing interfaces or message schema from an application system (see: Designing Interfaces), or both. You can begin the interface or message description at the same time as the further design steps and development in the business systems:

¡ If a stateful message processing is required on the Integration Server, define integration processes (see: Designing Cross-System Integration Processes). You use integration processes to define a stateful message processing that is executed on the Integration Server.

¡ To map the structure of a message to another message, use a message mapping or import an XSLT or Java archive. You use an interface mapping to specify which mapping programs to execute for which exchanged message for the source and target interface (see: Designing Mappings).

¡ To create executable proxies for message interfaces, use proxy generation. You use these proxies to connect applications on the SAP Web AS to the Integration Server (see: Proxy Runtime).

Result

The objects in the Integration Repository are assigned to a product using the software component version and can therefore be shipped with this product. Before they can be implemented in a system landscape at runtime, you must first configure the contents of the Integration Repository (see: Configuration).

Designing Integration Scenarios Developing Business Logic

Purpose

You use an integration scenario to define the message exchange and message flow for collaborative processes. Normally, these are processes between different business partners that are generally coupled by the exchange of messages.

The integration scenario provides you with a central point of access for all objects that you require for semantic and technical integration, for example interfaces, mappings, and software components.

You can integrate an executable integration process into an integration scenario.

The information entered in an integration scenario during the design phase is used as follows:

· During the configuration phase to map the collaborative process to the current productive system landscape.

In this phase you specify the business systems of the business partners on which the application components are installed. In this phase the integration scenario provides you with a central point of entry for the definition of all receiver determinations. These routing relations define the flow of messages in the productive system landscape.
For more information, see Configuration.

You can configure an integration scenario easily and concisely by using the integration scenario configurator. In particular, the configuration of business-to-business scenarios is supported.

· In productive operation to simplify the execution and administration of collaborative processes.

Integration scenarios make the dependencies between the business partners and the separation of concerns transparent. As a result, the entire collaborative process is easier to maintain, more reliable and more stable.

Features

The Integration Builder constitutes an integrated development environment for the design of integration scenarios. You can do the following with the Integration Builder:

· Define the business partners involved in the integration scenario and their application components

· Model all interactions for which messages are exchanged between different application components

· Specify each individual message exchange by assigning them interfaces and mappings

The development environment for integration scenarios comprises two editors:

· Integration scenario editor

The integration scenario editor provides an interactive graphical work area that enables you to visualize the integration scenario process and how the objects used are related to each other. From the context within this editor you can navigate to the object editors of all objects used. The top-down and bottom-up design of integration scenarios is supported.

· Action editor

The action editor enables you to display and edit actions. Actions are activities within the integration scenario process that are not subdivided further.

This section is structured around the following questions:

· What is an integration scenario and how do the various components work together? For more information, see Integration Scenario.

· How do I develop an integration scenario with the Integration Builder? For more information, see Integration Scenario Design Environment.

· How do I model an integration scenario? For more information, see Guidelines for Modeling Integration Scenarios.

Designing Integration Scenarios Integration Scenario

Definition

An integration scenario completely models the exchange of messages for a collaborative process and provides an overview of the process flow.

Structure

An integration scenario is a design object of the Integration Builder, is uniquely identified by a name and a namespace, and is subject to versioning.

To model the exchange of messages and the process flow, the integration scenario comprises the objects described below. The graphic shows how these objects are associated by using the demo example MultipleFlightBooking (see Booking Connecting Flights).

Integration Scenario MultipleFlightBooking and Objects Used

Objects of an Integration Scenario

· Application Component

· Action

· Interfaces and mappings

Interfaces define the data format of the messages that are used when messages are exchanged between actions from different application components. Furthermore, the properties of the interfaces involved determine whether communication takes place synchronously or asynchronously.

If mappings exist between outbound and inbound interfaces, then you can select a mapping for the integration scenario.

For more information about interfaces, see Designing Interfaces and Proxy Generation.

For more information about mappings, see Designing Mappings.

· Connection

Other Features of Integration Scenarios

· The beginning and end of a process run can be defined for an integration scenario. Selected actions can be defined as start actions and end actions for this purpose. There can be more than one start or end action.

· WSCI Interface

All descriptions of integration scenarios within the Integration Builder conform to WSCI (Web Service Choreography Interface) to create a basis for the standardized exchange of integration scenarios. A WSCI interface represents all the inbound and outbound channels (including dependencies) of an application component that is involved in an integration scenario. Therefore, each application component has a corresponding WSCI interface that needs to be named accordingly.

For more information about WSCI, see:

http://www.w3.org/TR/2002/NOTE-wsci-20020808/

See also:

· For detailed information about the semantic concepts, see Modeling Integration Scenarios.

Example

For examples of integration scenarios, see Demo Examples.

Designing Integration Scenarios Application Component

Definition

An application component is a modeling construct within an integration scenario. From a logical point of view, it represents a participant of an integration scenario. This contains the business tasks and concerns that this participant represents within the integration scenario.

An application component can stand for a business partner or a component of a business partner. At runtime it would be either one or more business systems or an integration process.

Structure

A product determines the tasks of an application component. Products are versioned. SAP APO 3.0A and SAP R/3 4.6C are examples of product versions. For further information about product versions, see Product Versions and Software Component Versions below.

The product of an application component can be any of the following:

· A product defined in the System Landscape Directory

· A main instance defined in the System Landscape Directory

· A template product when no corresponding product is defined in the System Landscape Directory or it is not specified in more detail at the time of design

With the latter you have the option of producing an integration scenario, the implementation of which is unknown or is not defined in the System Landscape Directory (for example, for non-SAP products).

Furthermore, application components are described by specifying a role. This role helps to specify the range of tasks of the application component on a business level. Examples of roles of different business partners are customers and vendors.

Application components are shown as colored columns in the integration scenario editor. Integration processes that are assigned to application components are indicated by the icon in the header of the application component.

Integration

Product Versions, Main Instances, and Software Component Versions

Product versions, main instances, and software component versions are defined in the System Landscape Directory. They play a central role in the definition of integration scenarios and are therefore explained briefly below:

Product versions are software units that can be installed on your system and that run independently of other software (for example: SAP R/3 4.6C). Product versions generally comprise multiple software component versions. Software component versions are independent development units at SAP that cannot function on their own and are not shipped as such (examples: SAP BASIS 4.6C, SAP APPL 4.6C, SAP HR 4.6C).

A main instance is a group of technically interdependent software component versions, which are all installed and run on one server. A main instance represents the smallest non-divisible unit within a system landscape.

In exceptional cases, a main instance may comprise a single software component version if this software component version is not dependent on any other software component technically.

Designing Integration Scenarios Action

Definition

An action represents a function within an application component that is not subdivided further. Actions subdivide the process flow of an integration scenario.

Actions are shown as white triangles in the integration scenario editor. The vertical progression of actions from top to bottom corresponds to the logical process flow.

An action is an independent design object of the Integration Builder. This means that actions are defined independently of integration scenarios. Thus you have the option of reusing actions in different integration scenarios.

Use

Usage Type for Actions

Label	Usage Type
Internal Actions	Defined for a ‘separate’ software component version. You can use internal actions in application components (of type Product Version or Main Instance) that (by using the product version) contain the same software component version in which the action is implemented.
External Actions	Defined for a software component version of a partner or for templates. You can use external actions in application components (of type Template or Product Version) that (by using the product version) contain the same software component version in which the integration scenario is implemented.

If you want to use an action to represent a function that is already installed in the product of the application component, use an internal action.

If you want to use an action to represent a function that is not yet provided by the product of the application component, use an external action.

In this way, you can enter functions in the integration scenario (for example, for communication parties) that are not yet provided by the product version of the application component.

For more information, see the modeling actions section.

All interfaces associated with an action are assigned to that action in the Integration Builder.

The exchange of messages between components takes places between two actions from different application components. The interfaces used in the exchange of messages are assigned to the two actions involved.

Designing Integration Scenarios Connection

Definition

A connection is a link between two actions within an integration scenario.

The following connection types exist:

· Sequence

Sequence represents the sequence of two actions within the same application component. A sequence is required for portraying the integration scenario process; however it contains no additional information.

· Cross-Component Connection

A cross-component connection connects actions from different application components with each other. These actions exchange messages with each other in an integration scenario. A cross-component connection defines the interfaces and mappings used.

Cross-component connections differentiate between synchronous and asynchronous communication (see Communication Parameters).

A connection is not an object that can be reused. It is only defined within a specific integration scenario.

Integration Scenario Design Environment

Purpose

In the integration scenario design environment of the Integration Builder, you can display and edit integration scenarios.

Integration

This section contains information about the object editors for the objects Integration Scenario and Action, including all functions and procedures associated with them.

Features

The integration scenario design environment contains two editors:

· Integration Scenario Editor

· Action Editor

In the navigation area, integration scenarios and actions are put in order of software component versions and namespace, and displayed under Integration Scenarios and Integration Processes. Note that in the navigation tree, actions are grouped under their software component version as independent design objects. This means that not all actions that are used in an integration scenario are displayed in the same position in the navigation tree as the integration scenario.

This section is structured as follows:

· Quick Start: Designing an Integration Scenario gives a step-by-step guide to creating a simple integration scenario for the first time.

· Action Editor explains how to use the action editor.

· Integration Scenario Editor explains how to use the integration scenario editor.

· Handling Messages describes what problems can occur and how best to resolve them.

Quick Start: Designing an Integration Scenario

Use

This section provides you with a step-by-step guide to defining a simple integration scenario. In the process, you will learn about the graphical modeling options available, how to insert application components, how to create actions, and how to define synchronous and asynchronous connections.

Prerequisites

· Software component version

Select a software component version in the navigation area of the Integration Builder.

You can

¡ Use an existing software component version

¡ Import a software component version from the System Landscape Directory

· A namespace in the software component version

You can do either of the following:

¡ Use an existing namespace

¡ Create a separate namespace

Procedure

Creating the integration scenario and inserting the application component

...

1. Expand the sub node of the selected namespace in the navigation area of the Integration Builder.

2. Select the Integration Scenario node and choose New ( ) from the context menu.

3. In the Create New Object dialog, enter the name of the integration scenario (FlightTripBooking) and confirm by choosing Create. The new integration scenario is opened in change mode.

4. In the field Description, enter Book Flight Trip.

5. To insert an application component for the travel agency, position the cursor on the graphical area and choose Insert Application Component from the context menu. The system displays the Insert Application Component dialog.

6. Select the radio button Template (Not Defined in System Landscape Directory) in the frame Application Component Type. Application components of type Template can be used if you do not want to specify a particular product specification.

7. In the frame Further Attributes, enter Travel Agency as the name of the role (field Role Name).

8. Confirm your specifications by choosing Apply. The application component for the travel agency then appears as a colored vertical column in the graphical display area of the integration scenario editor.

9. To insert the Airline application component, position the cursor on the graphical display area to the right of the travel agency application component and repeat steps 6 and 7. Enter Airline as the name of the role of the application component. You have now defined the application components required in the integration scenario.

Defining Actions

...

1. Select the Actions node in the navigation area for the selected namespace and choose New () from the context menu.

2. In the Create New Object dialog, enter the name of the action (BookFlightTrip) and confirm by choosing Create. The new action is opened in change mode.

3. In the field Description, enter Book Flight Trip.

4. In the Use group, choose the option Templates (Not Defined in System Landscape Directory) and save your entries.

You can only use the new action in the travel agency and airline application components you created if you select this option.

The new action is created in the same software component version in which you created the integration scenario.

5. To create additional actions, repeat steps 1-4.

¡ Action 2: Name ReserveSingleFlight; description Reserve Single Flight

¡ Action 3: Name PerformBookingForSingleFlight, description Book Single Flight

Save your entries each time. Unsaved actions cannot be used in the integration scenario.

Inserting actions and defining connections in the integration scenario

...

1. Navigate to the integration scenario.

2. To insert an action in the Travel Agency application component, in the graphical work area of the integration scenario editor, position the cursor on the colored column of the application component and choose Insert Action from the context menu.

In the Select Action dialog, select BookFlightTrip from the list of actions. The selected action is inserted in the application component. To move the action within the application component, use Drag & Drop by holding down the left mouse button. Move the action to the top of the application component column.

3. Next, insert ReserveSingleFlight at the top of the airline application component column, followed by PerformBookingForSingleFlight.

4. Lay out the actions as shown in the graphic above.

5. To create a synchronous connection between Book Flight Trip and Reserve Single Flight, proceed as follows:

Select both actions using the rubber band and then choose Create Connection Between Selected Actions from the context menu. The system calls the dialog for creating connections.

For more information about rubber bands and the other graphical functions of the integration scenario editor, see the Functions of the Graphical Editor section.

The relative position of the two actions means that the type of connection is automatically defined as synchronous. You do not need to make any further specifications. When you choose Apply, the dialog closes and a line is inserted between the selected actions to indicate synchronous communication.

6. To create an asynchronous connection between Book Flight Trip and Book Single Flight, proceed as follows:

Select the two actions as described in step 5. The relative position of the two actions means that the type of connection is automatically defined as asynchronous.

7. To create a sequence between Reserve Single Flight and Book Single Flight, proceed as follows:

Select the two actions and insert a connection. The relative position of the two actions means that the type of connection is automatically defined as Sequence.

8. To define start and end actions, proceed as follows:

Position the cursor on the Book Flight Trip action, and choose Define Action as Start Action from the context menu. The system inserts a start point above the action. Next, position the cursor on the Book Single Flight action, and choose Define Action as End Action from the context menu. The system inserts an end point beneath the action.

Defining interfaces and creating an example connection

...

1. In the graphical work area of the integration scenario editor, double click the Book Flight Trip action. The system calls the action editor. If the editor is not already in change mode, switch to change mode by choosing Switch Between Display and Edit Modes ( ).

2. In the Outbound Interfaces frame, choose Insert Empty Line Below Selected Line ( ). Enter FlightBookingReserveOut as the name of the interface in the name field. Leave the namespace field on the right empty.

3. You must now generate your new interface. To do so, position the cursor on the name field, and choose New ( ) from the context menu. They system calls the dialog for creating new objects. The object type Message Interface has already been selected. Select a namespace for the message interface and confirm your specifications by choosing Create.

4. The system calls the Message Interface: Change dialog. Enter Reserve Single Flight in the Description field. In the Attribute frame, choose Outbound for the direction and Synchronous for the mode. Save the interface.

Note that the interface is still not completely defined and cannot therefore be activated in the change list.

5. Using the tab pages at the bottom of the screen, navigate back to the action editor and save the changed Book Flight Trip action.

6. Navigate to the integration scenario editor and double click the Reserve Single Flight action. Following the procedure described in step 2, create a new Inbound Interface in this action with the name FlightBookingReserveIn.

7. Create the interface in the Message Interface: Change editor as described in step 3, but this time enter Reserve Single Flight in the Description field and specify the direction as Inbound. The mode is already set to synchronous. Save the interface and the Reserve Single Flight action.

8. Navigate to the integration scenario editor and open the connection editor for the synchronous connection by double clicking the connection line between the Book Flight Trip and Reserve Single Flight actions. The following interfaces are displayed at the bottom of the editor:

¡ Outbound interface created in the Book Flight Trip action

¡ Inbound interface created in the Reserve Single Flight action

9. Assign the interfaces to the connection by selecting both interfaces. To do so, select the corresponding check boxes. Choose Apply to confirm.

10. Save the integration scenario.

Integration Scenario Design Environment Action Editor

Use

You use the action editor to display and edit actions. Furthermore, you can assign one or more outbound or inbound interfaces to an action.

You do not define actions for specific integration scenarios and can therefore reuse them in different integration scenarios.

Prerequisites

You have created a new action or have opened an existing one.

For more information about creating objects in the Integration Builder, see Creating an Object.

For more information about opening objects in the Integration Builder, see Object Editors.

Features

The action editor comprises a header area and a work area.

Header

The action editor header displays the following information:

· Name and namespace

The name and namespace are part of the object key. The object key is defined when you create the action.

· Description

In this field you can enter a short description of the action in the language you logged on in. This description is then displayed in the integration scenario graphic when the action is used in an integration scenario. If you do not enter a description, the name of the action is displayed instead.

· Status

Displays the status of the object. For more information, see Object Editors.

Work Area

The work area is divided into three screen areas:

· Use

· Inbound Interfaces

· Outbound Interfaces

Screen Area Use

Here you define which application components the action can be used in. Select one of the two options by using the radio buttons:

· Internal (defined for separate software component versions)

· External (defined for partner software component versions or templates)

For more information, see Inserting Actions.

Note that the use cannot be changed once you have saved.

Screen Area Outbound/Inbound Interfaces

In this area you can assign interfaces to an action or remove any assignments already made.

The assigned interfaces are displayed in a table in the Inbound Interfaces and Outbound Interfaces areas. The name and namespace of each interface are displayed. For more information, see the Assigning Interfaces and Deassigning Interfaces sections of this documentation.

Functions for Managing and Editing the Table

Icon	Function
	Only in change mode (in the toolbar above the table or in the context menu when a line is selected): Inserts an empty line below the selected line.
	Only in change mode (in the toolbar above the table or in the context menu when a line is selected): Deletes the selected line.
	Only in change mode: In the toolbar above the table or in the context menu when a line is selected: Moves the selected line up or down.
	In the context menu; cursor positioned on a line with an interface: Opens the interface editor for the line selected.
	Only in change mode and only when an interface has been entered that has not yet been defined in the Integration Repository (in the context menu; cursor on the line with an interface): Creates a new message interface for this entry.
	Only in change mode (in the context menu; cursor positioned on a line with an interface): Calls the search help for message interfaces and imported objects (RFCs, IDocs); selection restricted to the software component version of the action.

Additional Display Functions

When you position the cursor on a table line, the following information about the interface is displayed in a quick info box:

· Message type

· Type (inbound, outbound or abstract)

· Mode (synchronous or asynchronous)

· Namespace

· Software component version

Integration Scenario Design Environment Assigning Interfaces

Use

You can assign one or more outbound or inbound interfaces to an action. These can be message interfaces, RFCs, or IDocs.

For more information about the different interface object types, see Introduction to Interface Development.

Note the following restrictions when assigning interfaces:

· The software component version of the interface must be the same software component version as the action in the case of internal actions. The name of the interface and the action do not have to be the same.

· There are no restrictions on external actions as far as the software component version of the inserted interface is concerned.

· Abstract interfaces can be inserted both as outbound and inbound interfaces.

· When assigning an inbound interface, it must be an inbound message interface, an RFC, or an IDoc.

· When assigning an outbound interface, it must be an outbound message interface, an RFC, or an IDoc.

Prerequisites

You have called the action editor and are in change mode.

Procedure

...

1. Depending on whether you want to assign an inbound or an outbound interface to the action, choose either Inbound Interfaces or Outbound Interfaces.

2. Choose Insert Empty Line Below Line Selected ().

3. You can call the search help in the inserted line. To do so, choose the search help icon () at the end of the table line. In the dialog Select Interface, select the interface you want to use.

Only those interfaces that match the criteria above are displayed in the dialog.

4. Select the interface and choose Ok.

You also have the option of assigning the action a message interface that has not yet been defined in the Integration Builder. To do so, carry out steps 1 and 2 above. In step 3, enter the name of the message interface manually in the corresponding field. You can also specify an appropriate namespace, if necessary.

This option is supported by the top-down approach: You have the option of modeling the interface initially as just part of an action, without having to define it as a development object in the Integration Builder first.

This can be done in the Integration Builder at a later stage. In the action editor, position the cursor on the interface in question and choose New () from the context menu. A message interface is then created with the name and the namespace being taken from the action editor. You can now define the properties of the interfaces.

This is only possible for message interfaces and not RFCs or IDocs.

Note that you can change the direction and mode of an interface during its design, but any changes you make will not be taken into account in the action editor or business scenario editor. This can therefore lead to inconsistencies.

Result

The interface is assigned to the action and the name of the interface is displayed in the Inbound Interface or Outbound Interface area of the action editor.

Deassigning Interfaces Integration Scenario Design Environment

Use

You can remove the assignment of an interface to a particular action.

Procedure

To deassign an interface, select the table line for the interface concerned and choose Delete Selected Lines ( ).

Ensure that the interface is not part of a connection in an integration scenario before removing the assignment. Otherwise, this will lead to inconsistencies in the integration scenario.

For more information about the corresponding message, see Handling Messages.

Result

The interface ceases to be assigned to the action and it is removed from either the Inbound Interface or Outbound Interface area of the action editor.

Integration Scenario Editor Enabling Application-to-Application Processes

Use

You use the integration scenario editor to display and edit integration scenarios. In the interactive graphical work area, you can visualize the integration scenario as a Component View. In a component view, you can display the process flow of an integration scenario and assign other objects, which define how messages are exchanged.

You can define multiple component views for an integration scenario.

Prerequisites

You have created a new integration scenario or have opened an existing one.

If multiple component views are defined for one integration scenario, you can select one component view after you have opened the integration scenario editor (see: Defining Multiple Component Views for an Integration Scenario).

Features

In the work area of the integration scenario editor, the name of the selected component view is displayed in the Component View Name field. At the bottom of the screen area there is an interactive graphical interface that you can use to visualize the process flow of the integration scenario and to assign all the required objects (component view). The structure of the component view is shown schematically in the following graphic. It also includes the various context-sensitive areas and the most important functions that can be called from the context menu.

Component View and Context-Sensitive Areas

The integration scenario objects are represented in the integration scenario editor as follows:

· Application components are portrayed as colored vertical columns. The colors of the columns are defined according to color conventions.

· The application component column has a header where the role, the name of the product with its release identifier (product version), and the extended name are displayed.

· Actions are portrayed as white rectangles within an application component. The vertical progression of actions from top to bottom corresponds to the logical process flow.

· Sequences are shown as vertical lines with an arrowhead beside the subsequent action. The sequence determines the order in which the actions are executed (see Connection).

· Synchronous connections are shown as horizontal lines with an arrowhead at each end. The two actions involved are on the same level in the graphic. This shows that the actions that are connected by such a connection are synchronized chronologically.

· Asynchronous connections are shown as bent lines with an arrowhead beside the subsequent action. The two actions involved here are not on the same level in the graphic. The subsequent action must be beneath the source action. This shows that the actions that are connected by such a connection are independent of each other and are not synchronized chronologically.

Functions for Assigning Objects and Defining a Connection

To assign objects to an integration scenario, call the functions specified below from the context menu. To call a function, position the cursor on a particular area within the integration scenario. The individual context-sensitive areas are represented in the integration scenario (see above). To call the editor to display or change an object, double click the object in question in the integration scenario.

Functions for Application Components

· Context: Graphical area is empty

¡ Insert Application Component

· Context: Application component (colored column):

¡ Display/Edit Application Component

¡ Remove Application Component

Functions in Actions

· Context: Application component (colored column)

¡ Insert Action

· Context: A selected action

¡ Display/Edit Action

¡ Remove Action

· Context: Multiple selected actions:

¡ Remove Actions

Functions for Connections

· Context: Two selected actions

¡ Create Connection Between Selected Actions

¡ Display/Edit Connection Between Selected Actions

¡ Remove Connection Between Selected Actions

Functions of the Graphical Editor

· See Functions of the Graphical Editor

Additional Functions

· Define Multiple Component Views

· Check the Configurability of a Component View

· Print and Export the Component View

Inserting an Application Component Integration Scenario Editor

Use

You can assign an integration scenario both an application component and a role. You must specify the implementing product version for the application component, including its extended name if applicable. Furthermore, you define the name of the WSCI interface for the application component.

Prerequisites

You have opened an integration scenario.

Procedure

...

1. Position the cursor on an empty space in the integration scenario graphic (in the integration scenario editor).

2. Choose Insert Application Component from the context menu.

The system displays the Insert Application Component dialog.

You can select the following types for the application component:

¡ Product Version (defined in System Landscape Directory)

¡ Main Instances (defined in System Landscape Directory)

¡ Template(when no corresponding product is defined in the System Landscape Directory)

For more information, see Modeling Application Components.

3. Select the relevant radio button in the Application Component Type frame.

¡ If you decide on Product Version or Main Instance, call the input help ( ) for the relevant field and choose a product version from the list.

The Associated Software Component Versions frame displays all software component versions that are assigned to this product version.

¡ If you choose Template, no entry is displayed in the Product Version field.

The Associated Software Component Version frame displays the software component version to which the integration scenario is assigned.

For more information, see Modeling Application Components.

4. On the Role tab page, specify the role of the application component (optional).

5. If the application component is to represent an integration process, choose the Integration Process ( ) tab page. Select the integration process (from the Integration Repository).

6. On the Other Attributes tab page, specify an extended name (optional).

The enhanced name can be used to do the following:

¡ Specify the function area of a product in more detail.

For example, you could specify the enhanced name SAP FIN for an application component with the product version SAP R/3 4.6C. This would indicate that this integration scenario is relevant for the subarea Financials.

¡ Specify the product name if the application component type is a template.

7. Specify a name for the WSCI interface (optional).

8. Choose OK.

Result

The system inserts an application component as a colored column in the graphical work area of the integration scenario editor. The column header displays the role, the product version, and the enhanced name.

Displaying/Editing Application Components Integration Scenario Editor

Use

You have the option of displaying or editing information about an application component.

Prerequisites

An integration scenario is open (integration scenario editor). This contains at least one application component.

To call the Display/Edit Application Component editor, either

· Double click the application component.

· Position the cursor on the application component and choose Display/Edit Application Component from the context menu.

If the application component is assigned an integration process (), you can either open the application component, or open the integration process directly.

·

Features

The Display/Edit Application Component editor is structured as follows:

...

Frame Application Component Type

This frame shows the application component type (by means of a radio button). This can be a Product Version, Main Instance or Template (see Application Component).

See also:

Modeling Application Components

Furthermore, the following information is also displayed:

· Communication Type

If you want to use the integration process to represent a cross-company process, you can use an application component to represent an external business partner by assigning the application component the type External Partner with B2B Communication (B2B component for short). Application components of this communication type are represented in the graphical integration scenario editor by the icon (in the header of the application component).

When you configure the integration scenario, the communication mode B2B communication is taken into account when generating the collaboration agreements (see Configuring Business-to-Business Scenarios).

An application component with the communication mode External Partner with B2B Communication cannot be assigned an integration process.

· Associated Software Component Versions

The information shown in this area varies according to the type of application component.

¡ In the case of product versions or main instances, the software component versions that are assigned to the product version are displayed.

¡ In the case of templates, the software component version to which the integration scenario is assigned is displayed.

Other information is displayed on the following tab pages:

Tab page Role

The role comprises a technical name and descriptive text.

The technical name must be unique in the integration scenario.

Tab Page Integration Process

If the application component is assigned an integration process (), the name of the integration process is displayed on this tab page.

You can only assign integration processes from the software component version of the application component.

Tab page Other Attributes

The other attributes here are the WSCI Name and an Extended Name. The Extended Name field cannot be used for the application component type Main Instance. In this case, the title of the main instance is displayed as the extended name.