Actions represent one of the functions provided by an application component within an integration 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).
SendSingleFlightBookingOrder
Description
The description gives a brief explanation of the business function of the action.
The text that you create in the description for an action is displayed in the integration scenario graphic when the action is used in an integration scenario.
Note the following conventions when writing the description:
· Create the description in English. Ensure that the original language is English.
If required, you can enter a description in German as well. In this case, ensure that the original language is German.
· Use the (technical) name of the action. If you create the description in the original language English, write the individual parts of the name separately.
· Do not write complete sentences.
· Keep the description as brief as possible so as not to complicate the integration scenario graphic unnecessarily.
· You can write a maximum of 250 characters. Abbreviate where appropriate, if applicable.
English example: Send single flight booking order
German example: Flugbuchungsauftrag senden
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.
Internal and External Actions
You can classify an action as either an internal or an external action.
· Internal actions are defined for a ‘separate’ software component version.
You can only use internal actions in application components of type Main Instance or Product Version; the software component version of the action must be part of the main instance or the product version in this case.
· External actions are defined for a software component version of a partner or for templates.
You can use external actions in application components of type Main Instance or Product Version (for any software component versions) or of type Template. In this case, the action must be implemented in the same software component version as the integration scenario.
Note the following uses of internal or external actions:
Use of Internal Actions
The action is an implemented action, in other words, the function implemented by the action is part of a known software component version.
Actions are used by default if the action represents an existing (implementing) function that is called by an interface. For this reason, the action is in the same software component as the function and the interface are implemented.
· Select internal (defined for a separate software component version).
· 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 integration scenarios in application components of type Main Instance or Product Version 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 integration 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 integration 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.
Use of External Actions
The action is a modeled action. In other words, the action represents a function in products not specified in more detail or a function in a software component version of a partner.
You should see actions as modeling aides when the function that the action in the integration scenario represents is not available (implemented).
· Select external (defined for separate software component versions of a partner or templates).
· Select the software component version of the integration scenario in which you want to use the action.
· You can use this action in application components of type Main Instance or Product Version (for any software component versions) or of type Template. The action must be implemented in the same software component version as the integration scenario.
· The action is shipped with its software component version. In other words, the action is always shipped together with the integration scenario in which it is used.
Reason
A modeled action 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 integration 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 also only be reused in integration 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 integration 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 integration 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 integration scenarios:
· All processes or process steps that require two different application components to communicate with each other must be represented as actions in the integration 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 integration scenario.
No comments:
Post a Comment