Modeling Actions 

Actions represent one of the functions performed by an application component within a Business Scenario.

Name

The name of an action is unique (within its namespace). The name is not language-specific. Special characters and blanks are not permitted.

Note the following conventions for names:

·        The action must have a meaningful business name. The name should be written in English so that it is globally understood.

Separate individual words by switching between upper and lower case characters (see the notes on naming conventions for design objects under Creating New Objects).

Example: SearchForFlightConnection

Description

The description gives a brief explanation of the business function of the action. It is language-specific and is displayed in the language you are logged on in. Note that description text is displayed in the Business Scenario graphic when the action is used in a Business Scenario.

Follow the usual conventions for short descriptions here. Keep the description as brief as possible so as not to complicate the Business Scenario graphic unnecessarily.

Example: Search for Flight Connection.

Assignments to a Software Component Version

You must assign a software component version to an action when you create it. This assignment has the following consequences:

·        It determines the software component versions that the action (as a design object of Integration Builder) is shipped to the customer with.

·        It determines the application components that the action can be used in.

For more information, see the following section.

Use in Products or Templates

You can use an action either in application components of type Product or of type Template. You cannot use an action in both types of application component. You must decide which you want to use when you create the action in the action editor.

Note the following:

...

       1.      The action is an implemented action, in other words, the function implemented by the action is part of a known software component version.

¡        Select to use the action in an application component of type Product (defined in the System Landscape Directory).

¡        Select the software component version in which the action is implemented. In other words, the implemented action always belongs to the implementing software component version.

¡        You can use this action in any Business Scenarios in all product versions for which the software component version of the action is part of the product version.

¡        The action is shipped with its software component version. In other words, the action is generally shipped independently of the business scenario in which it is used.

Reason:

You must be able to reuse an implemented action in the same way that the corresponding function is reused. Therefore, the action is defined in the software component version in which its function is implemented, and not in the software component version of the Business Scenario.

You define an action in the software component version SAP APO 3.0A. Since this software component version is part of the product version SAP APO 3.0A, you can use this action in all application components with this product version.

You define an action in the software component version SAP APO 4.6C. This software component version is part of multiple product versions (for example, SAP R/3 4.6C and SAP APO 3.0A). Therefore, you can use this action in all application components with such product versions.

       2.      The action is a modeled action. In other words, the action represents a function in products not specified in more detail.

¡        Select to use the action in application components of type Product (not defined in the System Landscape Directory).

¡        Select the software component version of the Business Scenario in which you want to use the action.

¡        You can only use this action in Business Scenarios that have the same software component version as the action. Also, you can only use the action in application components of type Template.

¡        The action is shipped with its software component version. In other words, the action is always shipped together with the Business Scenario in which it is used.

Reason:

A modeled action (for application components of type Template) does not belong to a particular software component version as far as its functions are concerned. Therefore, it is assigned to the software component version of the Business Scenario in which it is used. It is not recommended that you reuse the action on a large scale.For this reason, this action can likewise only be reused in Business Scenarios with the same software component version.

You define an action for application components of type Template in the software component version SAP APO 3.0A. You can use this action in all Business Scenarios that are assigned to the software component version SAP APO 3.0A, too.

Business Meaning of Actions

Note the following aspects when defining and selecting actions:

·        The granularity of actions should be based on the granularity of processes or process steps.

·        The local, business function that fulfills the task within the application component must be clear for each action (by using an appropriate name and documentation). Actions are the anchor points for the local functions of the application component.

·        Besides the connection to the local functions, actions must also provide a logical connection to the customizing settings that are required to use this part of a Business Scenario.

For more information about the level of detail of actions, see the section below.

Using Actions in Application Components

Note the following aspects about scope and level of detail when using actions in Business Scenarios:

·        All processes or process steps that require two different application components to communicate with each other must be represented as actions in the Business Scenario. If a local process only requires one (or a few) communication step(s), then you can model the whole process as one action. If a local process requires multiple communication steps, then the process must be modeled with numerous process steps.

·        You also have the option of modeling transitional steps within a local process that do not require any communication steps to other application components. However, you must only do so if it is vital for the clarity of the Business Scenario.