How-To Guide
SAP Policy Management
Document Version: 1.0 – 2015-04-30
CUSTOMER
SAP Policy Management 5.3 Guide for Implementing Business Transactions
2
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All
rights reserved.
SAP Policy Management 5.3
Typographic Conventions
Typographic Conventions
Type Style Description
Example Words or characters quoted from the screen. These include field names, screen titles,
pushbuttons labels, menu names, menu paths, and menu options.
Textual cross-references to other documents.
Example Emphasized words or expressions.
EXAMPLE Technical names of system objects. These include report names, program names,
transaction codes, table names, and key concepts of a programming language when they
are surrounded by body text, for example, SELECT and INCLUDE.
Example Output on the screen. This includes file and directory names and their paths, messages,
names of variables and parameters, source text, and names of installation, upgrade and
database tools.
Example Exact user entry. These are words or characters that you enter in the system exactly as they
appear in the documentation.
<Example> Variable user entry. Angle brackets indicate that you replace these words and characters
with appropriate entries to make entries in the system.
EXAMPLE Keys on the keyboard, for example, F2 or ENTER .
SAP Policy Management 5.3
Document History
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved. 3
Document History
Version Date Change
1.0 2015-04-30 First official version of this guide
4
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved.
SAP Policy Management 5.3
Table of Contents
Table of Contents
1 Introduction .................................................................................................................................................... 5 1.1 About this Document ............................................................................................................................................... 5 1.2 Terminology ............................................................................................................................................................. 5 1.3 Important Notes ....................................................................................................................................................... 6 1.4 Related Information and Further Useful Links ...................................................................................................... 6
2 General Comments on How to Implement a Business Transaction ........................................................ 7
3 Implementing a Business Transaction: Overview of Major Steps .......................................................... 9
4 Implementing a Business Transaction: Steps in Detail ........................................................................... 11 4.1 Repository Objects ................................................................................................................................................. 11
4.1.1 API Class of Business Transaction ....................................................................................................... 11 4.1.2 API Class for Executing a Business Transaction in the Background ............................................... 30 4.1.3 Business Components and Business Functions ............................................................................... 33 4.1.4 Data Container and Filler Classes ....................................................................................................... 36
4.2 PBT Models ........................................................................................................................................................... 42 4.2.1 Process Model for Business Transaction ........................................................................................... 42 4.2.2 Subcontroller Model ............................................................................................................................. 46
4.3 Internal Customizing ............................................................................................................................................ 50 4.3.1 Customizing of Control Parameters of a Business Transaction ...................................................... 50 4.3.2 Customizing of Control Parameters of Subprocesses ......................................................................55 4.3.3 Customizing of Completion Service ....................................................................................................55
4.4 IMG Customizing.................................................................................................................................................... 61 4.4.1 Customizing of Business Transactions ............................................................................................... 61 4.4.2 Defining Journal Entries ....................................................................................................................... 66 4.4.3 BTS Customizing .................................................................................................................................. 68 4.4.4 In-Force Business Configurator ........................................................................................................... 71 4.4.5 Business Transaction Folders ..............................................................................................................74
4.5 Service Enablement of Change Process and Business Transactions ...............................................................76 4.5.1 The Change API .....................................................................................................................................76 4.5.2 Executing Business Transactions by RFC ...........................................................................................78 4.5.3 Example: Execution of Business Transaction through Enterprise Services ................................... 86
4.6 Overview of Major BAdIs Relevant in the Context of Business Transactions ................................................. 88 4.7 Enhancement of Standard Business Transactions ........................................................................................... 90
4.7.1 Scenario A ............................................................................................................................................. 90 4.7.2 Scenario B ............................................................................................................................................. 90 4.7.3 Scenario C ............................................................................................................................................. 90 4.7.4 Scenario D ............................................................................................................................................. 95
SAP Policy Management 5.3
Introduction
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved. 5
1 Introduction
1.1 About this Document
This document contains information that customers and partners need to implement their own business transactions
for the Change business process of the Financial Services – Policy Management application. Most steps are identical in
both cases. Known deviations in the procedure for customers and partners will be mentioned explicitly.
This document also mentions some aspects of enhancing shipped business transactions. For a complete overview of
what has to be done to enhance a business transaction, you should also refer to the FS-PM Enhancement Guide.
This document serves as a guide and provides assistance when you face the task of implementing a new business
transaction. It describes in various degrees of detail all the steps that are needed to do this. It does not explain the
underlying technologies, such as PBT, or architecture, such as the use of data containers; this would considerably
exceed the scope of this guide.
With regard to the UI, this guide focuses on classic ABAP dynpro. By using background enabling for business
transactions, the data container architecture and control parameter Customizing (all issues are covered later on),
other UI technologies can also be used.
As of FS-PM Release 5.3, we further enabled the execution of business transactions in a service-oriented
implementation landscape and thus prepared the Change process to be run in an omnichannel environment. For
details regarding the service enablement of business transactions, see Service Enablement of Change Process and
Business Transactions. So, when using this guide for implementing new business transactions, you have to consider if
they shall be available in classic ABAP dynpro, in a service-oriented, omnichannel landscape or both.
This document is based on the assumption that the implementation of a new business transaction is possible without
the need for modification. If you feel the need for a modification when implementing a business transaction, we
encourage you to create a customer incident for SAP.
The description in this document is based on FS-PM Release 5.3. It is written for developers in partner organizations or
at the customer's site. It is assumed that the reader already has good skills in FS-PM development and is familiar with
the development framework of Policy-Based Technology (PBT).
1.2 Terminology
The following FS-PM-specific abbreviations are used in this guide:
Abbreviation Term
BTX Business Transaction
BTrans Business Transaction
BTS Business Transaction Scheduler
IM Insurance Mathematics
PBT Policy-Based Technology (FS-PM development framework)
IFBC In-Force Business Configurator
BP Business Process
6
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved.
SAP Policy Management 5.3
Introduction
Abbreviation Term
LoB Line of Business
FM Field modifiers
1.3 Important Notes
Caution
Read the following documents on last-minute changes:
o SAP Notes for additional information on findings discovered after release to customer. SAP Notes may
contain further links to main Notes for each release.
o ReleaseNotes.doc for additional information that might not be included in this document.
1.4 Related Information and Further Useful Links
For more information that is not covered in this guide, see below:
SAP Help Portal (http://help.sap.com/)
o SAP NetWeaver (information about Workbench, BAdIs, etc.)
o FS-PM itself
o Business Partner
o Organizational Management
o External systems such as:
o FS-CD
o FS-CM
o FS-ICM
o FS-RI
o And so on
Industry Solution Master Guide - SAP for Insurance (http://help.sap.com/insurance-pm)
SAP Policy Management: Enhancement Guide
Further information provided in the SAP for Insurance - Solution Manager Content
Online documentation
SAP Notes
SAP Policy Management 5.3
General Comments on How to Implement a Business Transaction
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved. 7
2 General Comments on How to Implement a Business Transaction
These are the major processing steps during the execution of a business transaction:
Figure: Process steps of a business transaction
The BTX process API class is responsible for executing and controlling all of these process steps. Therefore, it is of
central importance in this context and is described in detail in this guide.
Essentially, the BTX API class has the same duties in background mode as in dialog mode. A major difference is the
transfer of input data to the policy business object: In background mode, which is technically also used when executing
business transactions as a "service", as is described in Service Enablement of Change Process and Business
Transactions) this is handled by methods of the API class (PROCESS_ENTER_DATA). In dialog mode using classic
ABAP dynpro this is handled by subcontrollers. On reimplementation of a BTX, shifting of the effective date of a BTX,
revision of the data of a business transaction or resolving of the postdating of a BTX, the input data is retrieved in the
same way as for background execution of the BTX, even in dialog mode.
The description in this guide closely refers to the shipped business transaction Change Tariff Variant of the Change
business process, as an example. This business transaction has been chosen as a “representative” business
transaction as it includes all common functions of a business transaction without being too complex. For the
8
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved.
SAP Policy Management 5.3
General Comments on How to Implement a Business Transaction
description of how to build service-enabled business transactions, we will use Change Beneficiary as an example in the
Service Enablement of Change Process and business Transactions.
For this kind of business transaction, we deliver the superclasses /PM0/CL_ABP_BTX_MASTER and
/PM0/CL_ABP_BTX_MASTER_BTS. It is highly recommended that the API classes for the new business transaction
inherit from a copy of these superclasses, so that you are automatically supplied with the structure/methods that are
needed to get the business transaction running in dialog and background mode.
This guide also assumes that the business transaction to be implemented makes use of the superclasses. It provides
information about the circumstances under which a certain method has to be reimplemented. For more details, see
the comments in the methods of the superclasses.
Subprocesses usually have to implement their own subprocess API class to be reusable by different business
transaction API classes. Exceptions here are the subprocesses that are processed in dialog mode only, such as the
subprocess P_B_S_CNL_EXIT for leaving the application. With regard to Change Tariff Variant (PBT process model
P_B_S_TVR_AMD), you can find examples for subprocesses with their own API classes and how the communication
between BTX API and subprocess API works.
FS-PM provides wizards for generating the background data processing methods of the BTX API classes and the
interfaces used. The wizards can also be used to generate background data processing methods of the API classes for
subprocesses. A prerequisite for this is that the control parameters for the subprocess API to be generated have been
maintained in Customizing.
You can find detailed information on how to use the wizards in the online documentation of the wizards. The wizards
for generating the BTs data container interface and the background data processing methods are available in the
developer Customizing area /PM0/CUST_INT:
Caution
SAP does not guarantee that future changes in the shipped superclasses will be done in a way that no
adaptations of subclasses will be required.
Recommendation
Create local copies of the shipped superclasses in the partner or customer namespace and inherit data from
these copies. After upgrades, you should check for changes in the delivered superclasses.
SAP Policy Management 5.3
Implementing a Business Transaction: Overview of Major Steps
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved. 9
3 Implementing a Business Transaction: Overview of Major Steps
In this section, we outline the major steps required to implement your business transaction.
Recommendation
SAP recommends performing the steps listed below in this order.
Clarify the basic business requirements for the new business transaction:
o For which lines of business shall the business transaction be available?
o At which execution level(s) shall the business transaction be available?
o Which entities/fields shall be maintainable by the business transaction? Which ones are for display only? Shall
the business transaction be able to add or delete objects?
o Will the new business transaction directly maintain data of an external component (as the shipped business
transaction Change Commission Participant does with ICM via the PFO interface)? In this case, special
attention will be needed with regard to the issues of postdating, reversing, and reimplementing the business
transaction.
o Is communication with Insurance Mathematics required? Shall simulative calculation be offered in the dialog
of the business transaction?
o Are there conditions where the business transaction is available but should not be executable?
o Will the new business transaction need any special subprocesses, such as for editing an object in a detail view,
or if the business transaction shall be able to create new entities?
o Which journal entries shall be written by the business transaction?
o How shall taxes and charges be handled?
o Shall the business transaction support an alternative commission participant? Shall other objects be
accessible by the business transaction, for example in dialog mode through an ALV?
o Which components are relevant for the business transaction (Accounting, Commissions, Claims, Re-
Insurance, etc.) and have to be supplied by the business transaction?
o Clarify the requirements regarding postdating, reimplementation (with and without user interaction), shift of
effective date of the business transaction and revising business transaction data.
o Which new business functions will probably be required by the new business transaction?
Clarify the user roles (expert policy handler, sales agent, customer, call center agent, underwriter, etc.) that need
to execute the new business transaction, the implementation landscape (role-based portals, integration layers),
and the UI technologies to be supported.
Create the API class of the business transaction. Having clarified the business needs given above, you are able to
decide if your new API class can inherit from (a copy of) /PM0/CL_ABP_BTX_MASTER (this should be possible in
most cases), and which methods you have to specialize. For a detailed description of this step, see API Class of
Business Transaction.
Check if your business transaction can use one of the shipped completion service superclasses, or if you need a
new one. In the latter case, you should also inherit from a copy of one the shipped superclasses. For details, see
Customizing of Completion Service.
Create the BTS API class for orchestration of execution of the business transaction in background mode. Check if
the shipped superclass /PM0/CL_ABP_BTX_MASTER_BTS can be used here (this should be possible in most
10
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved.
SAP Policy Management 5.3
Implementing a Business Transaction: Overview of Major Steps
cases), or if you need to specialize from (a copy of) the shipped BTS superclass. For a detailed description of this
step, see API Class for Executing a Business Transaction in the Background.
If a new, background-enabled subprocess is required, create an API class for this subprocess.
Create a process model (or models, in case you need new subprocesses) in PBT Customizing with transaction
/PM0/3FW_START. For a detailed description of this step, see Process Model for Business Transaction.
Create dynpros, process contexts and subcontroller model (s) in PBT Customizing via transaction
/PM0/3FW_START. For a detailed description of this step, see Subcontroller Model.
In case your business transaction shall be enabled for background processing, clarify the needs regarding data
container issues. For a detailed description of this step, see Data Container and Filler Classes. Having done this,
the 2 API classes probably need adjustment.
Maintain the internal Customizing for the business transaction. For a detailed description of this step, see Internal
Customizing.
Maintain the IMG Customizing for the business transaction. For a detailed description of this step, see IMG
Customizing.
Assign the business transaction to a test template and test. For a detailed description of this step, see In-Force
Business Configurator.
Create or adapt business components and business functions as required by business needs and implement the
required BAdIs. For a detailed description of this step, see Business Components and Business Functions.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved. 11
4 Implementing a Business Transaction: Steps in Detail
This section uses the example of the Change Tariff Variant business transaction, as explained above. A description is
given as to which objects had to be implemented in which way to get this representative business transaction up and
running. It is pointed out when special requirements for a business transaction may require a different implementation
(for instance, a business transaction may or may not call the product engine, or a business transaction may or may not
support an alternative commission participant).
4.1 Repository Objects
4.1.1 API Class of Business Transaction
What does the API class of a business transaction do?
This API class processes the various steps during execution of a business transaction. It is used in dialog mode
(therefore it is customized in PBT as an attribute of the process model, see Process Model for Business Transaction)
as well as in background mode (here the execution of the business transaction is orchestrated by the BTS API class;
see API Class for Executing a Business Transaction in the Background and BTS Customizing).
The API class triggers the execution of business functions that are in /PM0/IF_ABP_BTX_PROCESS~CALCULATE and
it is also responsible for the technical data that is in /PM0/IF_ABP_BTX_TECH~CLEANUP. It contains methods that
are used both in dialog and background mode, such as /PM0/IF_ABP_BTX_PROCESS~INIT. Methods that are
executed in dialog mode only are named DLG*. And there are methods that are executed in background mode only,
such as PROCESS_ENTER_BTX_DATA.
The API class for the Change Tariff Variant business transaction is /PM0/CL_ABP_BTX_TVR_MASTER. It inherits from
/PM0/CL_ABP_BTX_MASTER.
Caution
The partner or customer-owned business transaction should not inherit from /PM0/CL_ABP_BTX_MASTER
but from a local copy of this superclass in the partner or customer namespace.
The functions for shifting the effective date of business transactions and revising business transaction data are
available. As both functions basically use the same technical implementation, some methods are used by both
functions in exactly the same way. For historical reasons, the technical names of these methods often refer to the shift
only.
Below is an overview of the superclass methods and their implementation in /PM0/CL_ABP_BTX_TVR_MASTER with
some hints for implementing your own business transactions:
Method: /PM0/IF_ABP_BTX_CHK_ACCESS~IS_AVAILABLE
Related business requirement: At which execution levels and for which product elements shall the
business transaction be available?
General purpose/use The superclass implementation executes the generally valid checks:
12
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
Method: /PM0/IF_ABP_BTX_CHK_ACCESS~IS_AVAILABLE
of superclass method Is the business transaction available at the execution level (checks against
control parameter Customizing)?
Is the business transaction available for the product element (checks against
assignment of business transactions to template in In-Force Business
Configurator)?
Availability in dialog mode, for example, means that the business transaction is
displayed in the context menu of a specific node.
This method does not need to be reimplemented as it executes checks that are
mandatory for every business transaction.
For shipped business transactions, you can implement the BAdI
/pm0/abp_btx_badi_mfim to add your own availability checks.
For partner- or customer-owned business transactions, you can also
reimplement method IS_AVAILABLE_BTXDEPENDENT to enhance with a
business transaction using your own checks.
Change Tariff Variant
implementation
As explained above, the method just inherits from the superclass.
Method: /PM0/IF_ABP_BTX_CHK_ACCESS~IS_EXECUTABLE
Related business requirement: Are there conditions where the business transaction shall not be
executable although it is available?
General purpose/use
of superclass method
The superclass implementation executes shipped mandatory checks that might
be overruled and customer-owned checks.
Checks are called overridable when they are executed in the standard shipment
but the result can be overridden by customer implementation.
Executable in dialog mode, for example, means that an available business
transaction is active in the context menu (it is not grayed out).
For a shipped business transactions, you can overrule certain checks oryou’re
your own checks by implementing the BAdI /pm0/abp_btx_badi_mfim.
For partner- or customer-owned business transactions, you can also
reimplement IS_EXECUTABLE_MNDTRY_BTX or
IS_EXECUTABLE_OVERRIDABLE_BTX.
In general this method does not need not to be reimplemented.
Change Tariff Variant
implementation
As explained above, the method just inherits from the superclass.
Two redefinitions were needed in these methods due to BTX-specific
requirements:
IS_EXECUTABLE_MNDTRY_BTX
IS_EXECUTABLE_OVERRIDABLE_BTX
Method: /PM0/IF_ABP_BTX_PROCESS~CALCULATE
Related business requirement: Does the business transaction require the call of the product engine?
Business-related checks and derivations that shall be executed when completing the business transaction.
General purpose/use
of superclass method
The superclass implementation executes the general steps before the call of the
product engine and before the call itself. The following steps are performed:
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved. 13
Method: /PM0/IF_ABP_BTX_PROCESS~CALCULATE
The BTX-specific checks (business functions) for the point of time END are done
in /pm0/cl_abp_check_and_derive=>check_and_derive_prcend. You can add
your own checks to shipped business transactions and your own business
transactions by implementing BAdI /pm0/abp_proc_derive_cust_badi
(if the calculation does not take place, this check should be done in the method
PRE_FINISH()).
Further preparations for the call of the product machine.
To determine the calculated data, the new-state data container is passed to the
calculate method of class /pm0/cl_abp_btx_gt.
In general, the BTX-specific reimplementation is not required. The logic in the
method is processed only in case the BTX really requires calculation, which is
determined in method GET_BTXPROCCTRL.
Change Tariff Variant
implementation
As mentioned above, the method just inherits from superclass.
Method: /PM0/IF_ABP_BTX_PROCESS~FINISH
Related business requirement: Finalize business transaction if it can be completed, e.g. provide
components
General purpose/use
of superclass method
The superclass implementation executes the general completion steps before
and after the call of the BTX-specific completion method finish_btxdependent().
The following general steps are required to complete the business transaction:
Set BO state to calculated
Write journal
Update time model
Finalize work by conclude service
Calculate the application deviations
Provide interfaces and components
Handle postdated state if the BTX is postdated
Clean up the conclude service
Close all transactions
In general, this method does not need to be reimplemented.
Change Tariff Variant
implementation
As mentioned above, the method just inherits from superclass.
Method: /PM0/IF_ABP_BTX_PROCESS~GET_PREDATE_TRIGGER
Related business requirement: Postdating of a business transaction
General purpose/use
of superclass method
If the business transaction is postdated, this method determines the origin for
postdating and, if supplied, the release date.
This method is commonly called by the BTS API class.
This method does not need to be reimplemented.
14
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
Method: /PM0/IF_ABP_BTX_PROCESS~GET_PREDATE_TRIGGER
Change Tariff Variant
implementation
As mentioned above, the method just inherits from superclass.
Method: /PM0/IF_ABP_BTX_PROCESS~HANDLE_CALC_ERRORS
Related business requirement: Does the business transaction require the call of the product machine?
General purpose/use
of superclass method
The superclass implementation handles the errors that occurred in the
calculation.
This method does not need to be reimplemented. The logic in the method is
processed only if the BTX really requires calculation, which is determined in the
method GET_BTXPROCCTRL.
Change Tariff Variant
implementation
As mentioned above, the method just inherits from the superclass.
Method: /PM0/IF_ABP_BTX_PROCESS~HANDLE_CALC_RESULTS
Related business requirement: Does business transaction require the call of the product engine?
General purpose/use
of superclass method
The superclass implementation handles the results of the calculation.
The method calls /PM0/CL_ABP_BTX_GT methods to handle
the calculation results from the product engine:
handle_calc_results
delete_inac tive_cov for deleting coverage selected by the product engine for
deletion.
UPDATE_PREMIUM_DIFFS for updating the premium differences between
states before and after changes.
This method does not need to be reimplemented. The logic in the method is
processed only if the BTX really requires calculation, which is determined in the
method GET_BTXPROCCTRL.
Change Tariff Variant
implementation
As mentioned above, the method just inherits from the superclass.
Method: /PM0/IF_ABP_BTX_PROCESS~HANDLE_FAILED_BTX_CONTEXT
Technical
General purpose/use
of superclass method
Handling/cleanup in case business transaction caused errors for one or more
execution levels.
This method does not need to be reimplemented.
Change Tariff Variant
implementation
As mentioned above, the method just inherits from the superclass.
Method: /PM0/IF_ABP_BTX_PROCESS~INIT
Related business requirement: Business-related checks and derivations that shall be executed when
starting the business transaction
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved. 15
Method: /PM0/IF_ABP_BTX_PROCESS~INIT
General purpose/use
of superclass method
The superclass implementation executes the required steps to initialize the BTX.
These include:
Setting old-state data container. To do this, the BTX-specific reimplementation
of the method create_old_state_dc_btxdpndnt() is required.
Open transaction
Set BO state to “in process”
Execution of business functions for point of time INIT. You can add your own
checks by to shipped business transactions and your own business transactions
by implementing BAdI /pm0/abp_proc_derive_cust_badi .
Handling of charges
Check for postdating and change of journal state
Handling of taxes
This method does not need to be reimplemented.
Change Tariff Variant
implementation
As mentioned above, the method just inherits from the superclass.
Method: /PM0/IF_ABP_BTX_PROCESS~PRE_FINISH
Related business requirement: Business-related checks and derivations that shall be executed when
completing the business transaction
General purpose/use
of superclass method
The superclass implementation includes process steps to prepare the
completion of the business transaction.
These includes:
Setting new-state data container. To do this, the BTX-specific reimplementation
of the method create_new_state_dc_btxdpndn() is required.
If the BTX does not call the insurance mathematics, the business functions
at the END point of time are executed through
/pm0/cl_abp_check_and_derive=>check_and_derive_prcend. You can add your
own checks to shipped business transactions and your own business
transactions by implementing BAdI /pm0/abp_proc_derive_cust_badi
BTX-specific executions are performed in the method
pre_finish_btxdependenT(), which must be reimplemented for customer-owned
business transactions.
Check for changes.
Handling of taxes.
This method does not need to be reimplemented.
Change Tariff Variant
implementation
As mentioned above, the method just inherits from the superclass.
16
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
Caution
When using a specialization (of a copy) of the super API class, make sure that the checks and derivations at
point of time END are called in /PM0/IF_ABP_BTX_PROCESS~CALCULATE for calculating business
transactions and in /PM0/IF_ABP_BTX_PROCESS~PRE_FINISH for non-calculating business transactions.
Method: /PM0/IF_ABP_BTX_TECH~CLEANUP
Technical
General purpose/use
of superclass method
Cleanup work when leaving the business transaction.
The BTX-specific cleanup takes place in the reimplementation of the method
tech_cleanup_btxdependent().
This method does not need to be reimplemented.
Change Tariff Variant
implementation
This method just inherits from the superclass.
Method: /PM0/IF_ABP_BTX_TECH~GET_METAINFO
Technical
General purpose/use
of superclass method
Sets values of the control parameters. These are determined from internal and
IMG Customizing, which is described in later sections.
This method does not need to be reimplemented.
Change Tariff Variant
implementation
This method just inherits from the superclass.
Method: /PM0/IF_ABP_BTX_TECH~SETUP
Technical
General purpose/use
of superclass method
The superclass implementation sets the data needed to start the business
transaction. The general settings include the following steps:
The BTX-specific setting can be implemented in the redefinition of the method
tech_setup_btxdependent().
Change Tariff Variant
implementation
This method just inherits from the superclass.
Caution
Subtransactions in a business transaction are always to be handled with the BTX transaction handler. Here is a
reference to it: /pm0/cl_abp_btx_trans_handler=>create_btx_trans_handler()
Method: DLG_CANCEL_EXIT_FROM_DIALOG
Technical
General purpose/use
of superclass method
Cleanup work when reversing the business transaction in dialog mode.
This method does not need to be reimplemented.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved. 17
Method: DLG_CANCEL_EXIT_FROM_DIALOG
This method is called in dialog processing only.
Change Tariff Variant
implementation
This method just inherits from the superclass.
DLG_CHECK_FOR_CHANGE
Related business requirement: The completion of the business transaction only makes sense if some
business-relevant data has changed.
General purpose/use
of superclass method
Determines if any data has changed.
The BTX-dependent reimplementation of the method
check_for_change_btxdependent() is required in this case.
This method is called in dialog processing only.
Change Tariff Variant
implementation
This method just inherits from the superclass.
DLG_CLEANUP
Technical
General purpose/use
of superclass method
Cleans up the data that was needed for the dialog, such as the navigation tree
state, property list, session stack.
This method does not need to be reimplemented.
This method is called in dialog processing only.
Change Tariff Variant
implementation
This method just inherits from the superclass.
DLG_CLEAR_LOGGER
Technical
General purpose/use
of superclass method
Deletes old error messages from the logger.
This method does not need to be reimplemented.
This method is called in dialog processing only.
Change Tariff Variant
implementation
This method just inherits from the superclass.
DLG_CNL_TRANS
Technical
General purpose/use
of superclass method
Cancels the open subtransaction and clears the member attribute
MF_DIRECT_APPROVE that triggers direct approval in a business transaction.
This method does not need to be reimplemented.
This method is called in dialog processing only.
Change Tariff Variant This method just inherits from the superclass.
18
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
DLG_CNL_TRANS
implementation
DLG_CTA_TRANS
Technical
General purpose/use
of superclass method
Closes the open sub transaction.
This method does not need to be reimplemented.
This method is called in dialog processing only.
Change Tariff Variant
implementation
This method just inherits from the superclass.
DLG_DEL_COMDIFF
Related business requirement: Business transaction allows maintenance of alternative commission
participants
General purpose/use
of superclass method
Handling of alternative commission participants in dialog mode.
This method does not need not to be reimplemented.
This method is called in dialog processing only.
Change Tariff Variant
implementation
This method just inherits from the superclass.
DLG_EXIT_FROM_COMDIFF
Related business requirement: Business transaction allows maintenance of alternative commission
participants
General purpose/use
of superclass method
The superclass implementation of the process method cleans up the data used
in the alternative commission participant subproces .
This method does not need to be reimplemented.
This method is called in dialog processing only.
Change Tariff Variant
implementation
This method just inherits from the superclass.
P_B_P_APPROVE
Technical
General purpose/use
of superclass method
The superclass implementation of the process method sets the member
attribute MF_DIRECT_APPROVE. This member attribute triggers the direct
approval after the business process is completed. Therefore it is handled in the
last process node implemenation DLG_EXIT_FROM_DIALOG. This method is
called when the business transaction dialog is exited with the command
CMD_F_XCT_APPR (‘Complete and Release’ button).
This method does not need to be reimplemented.
This method is called in dialog processing only.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved. 19
P_B_P_APPROVE
Change Tariff Variant
implementation
This method just inherits from the superclass.
DLG_EXIT_FROM_DIALOG
Technical
General purpose/use
of superclass method
Cleans up the data when leaving the business transaction in dialog mode.
This method does not need to be reimplemented.
This method is called in dialog processing only.
Change Tariff Variant
implementation
This method just inherits from the superclass.
DLG_PREPARE_COMDIFF_ADD
Related business requirement: Business transaction allows maintenance of alternative commission
participants
General purpose/use
of superclass method
The superclass implementation of the process method prepares data required
for the subprocess Add Alternative Commission Participant by calling the
method mr_btx_api_sub_comdiff->setup().
This method does not need to be reimplemented.
This method is called in dialog processing only.
Change Tariff Variant
implementation
This method just inherits from the superclass.
DLG_PREPARE_COMDIFF_MOD
Related business requirement: Business transaction allows maintenance of alternative commission
participants
General purpose/use
of superclass method
The superclass implementation of the process method prepares data required
for the subprocess Change Alternative Commission Participant by calling the
method mr_btx_api_sub_comdiff->setup().
This method does not need to be reimplemented
This method is called in dialog processing only.
Change Tariff Variant
implementation
This method just inherits from the superclass.
DLG_PREPARE_FOR_DIALOG
Technical
General purpose/use
of superclass method
The superclass implementation sets up the data required for dialog processing
by executing following steps:
Set navigation tree status disabled
Put BTX parameter and BTX ID on the session stack
20
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
DLG_PREPARE_FOR_DIALOG
Call the BTX-specific method dlg_prepare_for_dialog_btx().
This method does not need to be reimplemented. Only the BTX-specific method
dlg_prepare_for_dialog_btx() should be reimplemented.
This method is called in dialog processing only.
Change Tariff Variant
implementation
This method just inherits from the superclass.
DLG_PREPARE_FOR_DIALOG_BTX
technical
General purpose/use
of superclass method
If needed, this method can be reimplemented by partner or customer owned
business transactions.
This method is called in dialog processing only.
Change Tariff Variant
implementation
This method just inherits from the superclass.
DLG_REDO_LOAD
Related business requirement: Reimplementation of business transaction
General purpose/use
of superclass method
Loads the redo data (the data maintained in the original execution of the BTX)
in the application in dialog mode.
This method does not need to be reimplemented.
Only the BTX-specific method dlg_redo_load_btxdependent() can be
reimplemented.
This method is called in dialog processing only.
Change Tariff Variant
implementation
This method just inherits from the superclass.
DLG_SHIFT_LOAD
Related business requirement: Shift of effective date of a BTX; Revise business transaction data
General purpose/use
of superclass method
Loads the shifted data (the data maintained in the original execution of the BTX
with adjusted dates) or, in case of a revision, the original data in the application
in dialog mode.
This method does not need to be reimplemented.
This method is called in dialog processing only.
Change Tariff Variant
implementation
This method just inherits from the superclass.
DLG_REDO_LOAD_BTXDEPENDENT
Related business requirements: Reimplementation
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved. 21
DLG_REDO_LOAD_BTXDEPENDENT
General purpose/use
of superclass method
If needed, this method can be reimplemented by partner- or customer-owned
business transactions.
This method is called in dialog processing only.
Change Tariff Variant
implementation
This method just inherits from the superclass.
DLG_SHIFT_LOAD_BTXDEPENDENT
Related business requirements: Shift of effective date of business transaction and revision of business
transaction data
General purpose/use
of superclass method
If needed, this method can be reimplemented by partner- or customer-owned
business transactions.
This method is called in dialog processing only.
Change Tariff Variant
implementation
This method just inherits from the superclass.
DLG_SWITCH_REDO_SHIFT
Related business requirements: Reimplementation, shift of effective date of business transaction and
revision of business transaction data
General purpose/use
of superclass method
This method is called after the ‘Data Transfer’ button is called during the
reimplementation or shift of effective date or the revision of business transaction
data. It decides whether the successor DLG_REDO_LOAD (reimplementation) or
DLG_SHIFT_LOAD (shift of effective date) should be called.
This method does not need to be reimplemented.
This method is called in dialog processing only.
Change Tariff Variant
implementation
This method just inherits from the superclass.
DLG_REDO_RESET
Related business requirements: Reimplementation, shift of effective date of business transaction and
revision business transaction data
General purpose/use
of superclass method
Resets in dialog mode the data to the state before execution of the business
transaction.
This method does not need to be reimplemented.
This method is called in dialog processing only.
Change Tariff Variant
implementation
This method just inherits from the superclass.
DLG_REFRESH_LOGGER
Technical
22
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
DLG_REFRESH_LOGGER
General purpose/use
of superclass method
Deletes old messages from the logger.
This method does not need to be reimplemented.
This method is called in dialog processing only.
Change Tariff Variant
implementation
This method just inherits from the superclass.
DLG_RESET_ERROR_BEFORE_DIALOG
Technical
General purpose/use
of superclass method
Resets the error flag of the failed keys (execution levels)
before displaying the dialog; Otherwise the following activities would
not process them. It also resets all provided interfaces and components.
This method does not need to be reimplemented.
This method is called in dialog processing only.
Change Tariff Variant
Implementation
This method just inherits from the superclass.
CALL_TAX_SETUP
Related business requirement: Handling of tax relevance of a BTX.
General purpose/use
of superclass method
Calls set up for the taxation subprocess. All shipped business transactions are
prepared for handling taxes.
This method does not need to be reimplemented.
Change Tariff Variant
implementation
As mentioned above, the method just inherits from the superclass.
CHECK_FOR_CHANGE
Related business requirement: Completion of the business transaction should only be allowed if business-
relevant data has been changed.
General purpose/use
of superclass method
Determines whether the changes that have been made during the
business transaction legitimate its completion.
The method check_for_change_btxdependent() must be reimplemented by any
BTX.
Change Tariff Variant
implementation
This method just inherits from the superclass.
CHECK_FOR_CHANGE_BTXDEPENDENT
Related business requirement: Completion of the business transaction should only be allowed if the
business-relevant data has been changed.
General purpose/use
of superclass method
Must be reimplemented by any BTX.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved. 23
CHECK_FOR_CHANGE_BTXDEPENDENT
Change Tariff Variant
implementation
For shipped business transactions, the checks are done in an implementation of
a BTX-specific BAdI. In the case of Change Tariff Variant, the BAdI is
/pm0/abp_tvr_check_badi, and the method is
/PM0/IF_ABP_TVR_CHECK_BADI~check_amendment_concl_allowed().
The two data containers new-state and old-state must be passed to the method
for comparison reasons.
If no changes were made, the transaction is cannot be completed.
CHECK_REDEFINITION_NEEDED
Technical: In each BTX-specific class, there are some methods that
should be reimplemented (or at least checked if a redefinition
is necessary).
General purpose/use
of superclass method
Check to ensure that such methods are redefined when called.
This method can be redefined by BTX.
Change Tariff Variant
implementation
This method just inherits from the superclass.
CHK_EXEC_ALLOWED_ON_LEVEL_BTXD
Related business requirement: Executability of a business transaction at certain levels
General purpose/use
of superclass method
Checks if the execution of the BTX is allowed for the given level. This method
can be implemented if you want to install further checks other than those that
check the control parameter Customizing.
Change Tariff Variant
implementation
This method just inherits from the superclass.
CREATE_NEW_STATE_DC_BTXDPNDNT
Related business requirement: New state of application is needed for processing during completion of
business transaction
General purpose/use
of superclass method
Stores BTX-specific data at the end of the BTX in a data container that is passed
to the complete service or to check for changes. This content is then used for an
analysis of the new state.
Change Tariff Variant
implementation
Creates an instance reference of the BT- specific data container.
CREATE_OLD_STATE_DC_BTXDPNDNT
Related business requirement: Old state of application is required for processing during completion of
business transaction
General purpose/use Stores BTX-specific data at start of BTX in a data container which is passed to
24
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
CREATE_OLD_STATE_DC_BTXDPNDNT
of superclass method the complete service or to check for changes. This content is then used for an
analysis of the old state.
The method is processed only if ms_btxproccntrl_info-oldstatedc_req_fg is set,
but this is often needed. So this method usually needs to be reimplemented.
Change Tariff Variant
implementation
Creates an instance reference of the BTX-specific data container.
GET_BTXPROCCTRL
Business related requirement: Sets the default values for some parameters that determine the behavior
of the BTX.
General purpose/use
of superclass method
Sets values of some BTX control parameters at run time.
These values can be overridden or BTX-specific values can be set in
get_btxprocctrl_btxdependent().
This method does not need to be reimplemented.
Change Tariff Variant
implementation
This method just inherits from the superclass.
GET_BTXPROCCTRL_BTXDEPENDENT
Business-related requirement: Sets the BTX-specific values for some parameters that determine the
behavior of the BTX.
General purpose/use
of superclass method
If required, this method can be reimplemented by partner- or customer-owned
business transactions.
Change Tariff Variant
implementation
This method is reimplemented by the BTX to set values for additional
parameters.
GET_REDO_CMD_INIT_BTXDEPENDENT
Technical
General purpose/use
of superclass method
If required, this method can be reimplemented by partner- or customer-owned
business transactions.
Special issue for a shipped business transaction. Should not be required for
customer- or partner-owned BTX.
Change Tariff Variant
implementation
This method just inherits from the superclass.
IS_AVAILABLE_BTXDEPENDENT
Related business requirement: Availability of a business transaction.
General purpose/use BTX-dependent checks for the availability of the BTX.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved. 25
IS_AVAILABLE_BTXDEPENDENT
of superclass method If required, this method can be reimplemented by partner- or customer-owned
business transactions.
Change Tariff Variant
implementation
This method just inherits from the superclass. The checks executed in
/PM0/IF_ABP_BTX_CHK_ACCESS~IS_AVAILABLE of
/PM0/CL_ABP_BTX_MASTER are sufficient here.
IS_EXECUTABLE_MNDTRY
Related business requirement: Are there conditions where the business transaction is not executable
although it is available?
General purpose/use
of superclass method
Mandatory checks valid for each BTX to evaluate if the BTX is executable.
Can be reimplemented for your own business transactions, but this should be
done with great care.
Change Tariff Variant
implementation
This method just inherits from the superclass.
IS_EXECUTABLE_MNDTRY_BTX
Related business requirement: Are there conditions where the business transaction is not executable
although it is available?
General purpose/use
of superclass method
BTX-specific mandatory checks to evaluate if the BTX is executable.
If there are BTX-specific mandatory checks for business transaction owned by
partners or customers, implement them here.
Change Tariff Variant
implementation
This method is reimplemented by the BTX. The check that assures that there is
a recurring premium is not mandatory in general, but it is for this BTX. This
check should not be overridden, that is why it is done here.
IS_EXECUTABLE_OVERRIDABLE
Related business requirement: Are there conditions where the business transaction is not executable
although it is available?
General purpose/use
of superclass method
Generally valid checks that are executed by default for shipped business
transactions, but the result of these can be overridden by partners or customers.
For partner-owned BTXs, checks that are run by default but are overridable by
customers should be implemented here. For customer-owned BTXs, it is
probably of no use.
Change Tariff Variant
implementation
This method just inherits from the superclass.
IS_EXECUTABLE_OVERRIDABLE_BTX
Related business requirement: Are there conditions where the business transaction shall not be
executable although it is available?
26
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
IS_EXECUTABLE_OVERRIDABLE_BTX
General purpose/use
of superclass method
BTX-specific checks that are executed by default for shipped business
transactions, but the result of these can be overridden by partners or customers.
For partner-owned BTXs, checks that are run by default but are overridable by
customers should be implemented here. For customer-owned BTXs, it is
probably of no use.
Change Tariff Variant
implementation
This method is reimplemented by the BTX. For example, the check that the
contract is not in suspension is specific for this BTX should be executed by
default, but the result can be overridden by partners or customers.
IS_FUNDSRELATED
Related business requirement: Business transaction can cause investments or disinvestments in funds.
General purpose/use
of superclass method
Checks from the completion service Customizing if the fund-btx-id differs from
NFBTX_ID. If so, funds relevance of the BTX is assumed.
This method does not need to be reimplemented.
Change Tariff Variant
implementation
This method just inherits from the superclass.
PRE_FINISH_BTXDEPENDENT
Related business requirement: Business-related processing steps before completing the business
transaction
General purpose/use
of superclass method
If required, this method can be reimplemented by partner- or customer-owned
business transactions.
Change Tariff Variant
implementation
This method just inherits from the superclass.
FINISH_BTXDEPENDENT
Related business requirement: Finalize business transaction if it can be completed, e.g. provide
components.
General purpose/use
of superclass method
If required, this method can be reimplemented by partner- or customer-owned
business transactions.
Change Tariff Variant
implementation
This method just inherits from the superclass.
PROCESS_DETERMINE_BTX_DATA
Related business requirement: Business-relevant data specific for the business transaction
Note
If only SAP-owned entities of the Policy business object are customized as input entities of the
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved. 27
PROCESS_DETERMINE_BTX_DATA
BTX the coding of this method can be generated by a wizard that is started with transaction
/PM0/ABX_BACKAPI. The BTX data container interface that is used can be generated as well,
by the wizard is started in transaction /PM0/ABX_INFGEN.
General purpose/use
of superclass method
Determines the relevant data for the BTX that is contained in the data container
passed to this method and sets them in a BTX-specific data container.
As each business transaction accesses its specific entities, this method will
need to be reimplemented for any BTX owned by partners or customers.
This methods calls, entity by entity, private methods for each entity that can be
maintained by the BTX. If such entities are processed by subprocesses it also
determines this data by calling process_determine_data of the subprocess API.
Change Tariff Variant
implementation
In the standard shipment, this BTX can at maximum maintain the entities for
contracts, premiums, and valid date. It also offers a detailed view for coverages
as well.
Thus the following entities are set in the data container in the method
reimplementation for this BTX:
Contracts
Premiums
Valid date
The subprocess API coverage detail is set up.
PROCESS_ENTER_BTX_DATA
Related business requirement: Data must be entered in background processing
Note
If only SAP-owned entities of the Policy business object are customized as input entities of the
BTX, the coding of this method can be generated by a wizard that is started with transaction
/PM0/ABX_BACKAPI.
General purpose/use
of superclass method
Reads the BTX-relevant data from the persistent data container and merges it
with the Application business object.
As each business transaction maintains its specific entities, this method will
need to be reimplemented for any BTX owned by partners or customers.
This method calls private methods, for each entity and operation mode
(modification, adding, and deletion) relevant for the BTX. If such entities are
processed by subprocesses, it also processes this data by calling the
process_enter_data of the subprocess API.
Change Tariff Variant
implementation
All necessary execution steps of entering data in background processing are
done in this method. According to the relevant entities and operations for this
BTX, the following private methods are called:
MOD_PREM() - Changes Premium (Basis)
MOD_POLPR() - Changes Contract Data (Basis)
MOD_LL_VALID() - Changes Value Date (Life)
MOD_LL_PREM() - Changes Premium (Life)
28
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
PROCESS_ENTER_BTX_DATA
MOD_LL_POLPR() - Changes Contract Data (Life)
Corresponding method of the subprocess API coverage detail is called.
PROCESS_ENTER_CHARGE_DATA
Related business requirement: Charges can be assigned to a business transaction that can be manually
edited.
General purpose/use
of superclass method
The superclass implementation in background mode enters the charges data by
calling the method of the charge API class mr_abv_charge_api-
>process_polpr_charges(). A separate data container for charges is used for
this.
This method does not need to be reimplemented.
Change Tariff Variant
implementation
This method just inherits from the superclass.
PROCESS_ENTER_COMDIFF_DATA
Related business requirement: Alternative commission participants can be maintained for a business
transaction.
General purpose/use
of superclass method
The superclass implementation in background mode enters the commission
data by calling the methods of subprocess API class
/PM0/CL_ABP_SUB_BTX_COMDIF_AMD:
mr_btx_api_sub_comdiff->setup()
mr_btx_api_sub_comdiff->init()
mr_btx_api_sub_comdiff->process_enter_comdiff_data()
mr_btx_api_sub_comdiff->pre_finish()
mr_btx_api_sub_comdiff->finish()
and so on.
To load the data in background mode, a separate data container for commission
participants is used.
This method does not need to be reimplemented.
Change Tariff Variant
implementation
This method just inherits from the superclass.
PROCESS_ENTER_TAX_DATA
Related business requirement: Taxation handling is needed for a business transaction.
General purpose/use
of superclass method
The superclass implementation in background enters the tax data by calling the
method of the tax API mr_tax_btx_api->process_enter_tax_data().
To load the data in background mode, a separate data container for commission
participants is used.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved. 29
PROCESS_ENTER_TAX_DATA
This method does not need to be reimplemented.
Change Tariff Variant
implementation
This method just inherits from the superclass.
PROVIDE_COMPONENTS
Related business requirement: Different components in the FS-PM application must be provided with data
when completing the business transaction.
General purpose/use
of superclass method
The superclass implementation provides the following components with data
depending on the “required” flag:
Charges by calling /pm0/cl_abp_btx_gt=>provide_charges()
Cashflow handling business transaction independent by calling
/pm0/cl_abp_btx_gt=>provide_cashflow_bp()
Cashflow handling business transaction dependent by calling
/pm0/cl_abp_btx_gt=>provide_cashflow_btx()
Correspondence by calling /pm0/cl_abp_btx_gt=>plan_corr()
This method does not need to be reimplemented.
Change Tariff Variant
implementation
This method just inherits from the superclass.
PROVIDE_INTERFACES
Related business requirement: The interfaces to other installed applications must be supplied with data
General purpose/use
of superclass method
The superclass implementation provides the following interfaces with data
depending on the “required” flag:
PFO interface by calling /pm0/cl_abp_btx_gt=>provide_pfo()
Collections and Disbursements interface by calling
/pm0/cl_abp_btx_gt=>provide_cd()
Commission interface by calling /pm0/cl_abp_btx_gt=>provide_cs()
Claims interface by calling /pm0/cl_abp_btx_gt=>provide_cm()
Business Partner interface by calling
/pm0/cl_abp_btx_gt=>provide_partner_intf()
This method does not need to be reimplemented.
Change Tariff Variant
implementation
This method just inherits from the superclass.
TAKE_SNAPSHOT
Related business requirement: Keep parts of the application objects for further usage
General purpose/use
of superclass method
By calling this method, you can take a snapshot of parts of the business object.
This method is mainly for historical reasons. Partner- and customer-owned
business transactions should not need to make use of the snapshot.
30
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
TAKE_SNAPSHOT
Change Tariff Variant
implementation
This method just inherits from the superclass.
TECH_CLEANUP_BTXDEPENDENT
technical
General purpose/use
of superclass method
The BTX-specific cleanup work takes place in this method.
This method can be reimplemented.
Change Tariff Variant
implementation
Empty implementation, nothing to be done here for this BTX.
TECH_SETUP_BTXDEPENDENT
technical
General purpose/use
of superclass method
The BTX-specific setup takes place in this method.
As different lines of business are relevant for each BTX, this method needs to be
reimplemented for customer- and partner-owned business transactions, at least
to initialize the so-called UBOI wrappers.
Change Tariff Variant
implementation
The wrappers for Basis and LIFE are created. In the standard delivery, this
business transaction does not maintain P&C siblings.
EXTINCT_CLONE
Technical
General purpose/use
of superclass method
Clean up the clone if there is one.
This method does not need to be reimplemented.
FS-PM offers the possibility of cloning the business object and working on the
clone in dialog mode. This is done for a few shipped business transactions. For
partners and customers, we highly recommend avoiding the need to clone the
business object.
Change Tariff Variant
implementation
This method just inherits from the superclass.
4.1.2 API Class for Executing a Business Transaction in the Background
What is the purpose of the BTS (Business Transaction Scheduler) API class?
Background execution of a business transaction is always executed as a BTS date (see BTS Customizing). The BTS
API class is the mediator between the BTS Framework and the API class of the business transaction. According to the
customized BTS work steps, the BTS API class is responsible for executing the methods of the BTX API class that are
needed in background processing.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved. 31
Note
Resolution of postdated business transactions and the reimplementation of reversed business transactions is
also handled as background processing triggered by BTS dates.
When executing a business transaction as a service, BTS is also used, but in a less extensive manner. See Service
Enablement of Change Process and Business Transactions.
A BTS API superclass /PM0/CL_ABP_BTX_MASTER_BTS is part of the standard shipment. This superclass (or to be
more precise, a copy of it) should only need to be redefined for a new business transaction in very rare cases. Change
Tariff Variant also just uses the master.
Here is a short description of the methods of /PM0/CL_ABP_BTX_MASTER_BTS, as well as the relevant BTS work
steps (see BTS Customizing).
Method: /PM0/IF_ABP_BPU_BTX_BTS~CHECK
Related business requirement: It must be verified in background mode if the
business transaction can be executed.
General purpose/use
of superclass method
The implementation of the method checks if the
business transaction can be executed for the given keys.
The BTX API methods:
/pm0/if_abp_btx_chk_access~is_available()
/pm0/if_abp_btx_chk_access~is_executable()
are executed here.
For Change Tariff Variant, this method is called in work step 20
(/PM0/CL_ABP_BTSWS_BPA_CHECK) of BTS ID BPA_TVR_AMD.
Method: /PM0/IF_ABP_BPU_BTX_BTS~CLOSE_BTX
Related business requirement: The business transaction must be completed in background mode.
General purpose/use
of superclass method
The implementation of the method
completes processing of the business transaction.
The methods:
/pm0/if_abp_btx_process~finish()
/pm0/if_abp_btx_process~get_predate_trigger()
/pm0/if_abp_btx_process~handle_failed_btx_context()
/pm0/if_abp_btx_tech~cleanup()
of the BTX API are executed here.
For Change Tariff Variant, this method is called in work step 90
(/PM0/CL_ABP_BTSWS_BPA_CLOSEBTX) of BTS ID BPA_TVR_AMD.
Method: /PM0/IF_ABP_BPU_BTX_BTS~INIT_BTX
Related business requirement: The business transaction must be initialized in background mode.
General purpose/use
of superclass method
The implementation of the method initializes the business transaction.
The methods:
32
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
Method: /PM0/IF_ABP_BPU_BTX_BTS~INIT_BTX
/pm0/if_abp_btx_process~init() (of BTX API)
init_btxdependent() are executed here.
For Change Tariff Variant, this method is called in work step 40
(/PM0/CL_ABP_BTSWS_BPA_INITBTX) of BTS ID BPA_TVR_AMD.
Method: /PM0/IF_ABP_BPU_BTX_BTS~INIT_BTX_CONTAINER
Related business requirement: initialization of BTX data container in background mode.
General purpose/use
of superclass method
The implementation of the method initializes the BTX container.
The BTX API method
process_determine_btx_data() is executed here.
For Change Tariff Variant, this method is called in work step 60
(/PM0/CL_ABP_BTSWS_BPA_INITCC) of BTS ID BPA_TVR_AMD.
Method: /PM0/IF_ABP_BPU_BTX_BTS~POSTPROCESSING
Related business requirement: After the call of product engine, the calculation results must be handled in
background mode.
General purpose/use
of superclass method
The implementation of the method
processes the business transaction after the call of the product engine.
The methods:
/pm0/if_abp_btx_process~handle_calc_results()
/pm0/if_abp_btx_process~pre_finish()
/pm0/if_abp_btx_process~get_predate_trigger()
of BTX API are executed here.
For Change Tariff Variant, this method is called in work step 80
(/PM0/CL_ABP_BTSWS_BPA_POSTPROC) of BTS ID BPA_TVR_AMD.
Method: /PM0/IF_ABP_BPU_BTX_BTS~POSTPROCESSING_ERRCS
Related business requirement: After the call of the product engine, potential errors must be handled in
background mode.
General purpose/use
of superclass method
The implementation of the method processes the error messages after the call
of product engine for the business transaction.
The methods:
/pm0/if_abp_btx_process~handle_calc_errors()
/pm0/if_abp_btx_process~get_predate_trigger()
of BTX API are executed here.
This method is called by the BTS core framework.
Method: /PM0/IF_ABP_BPU_BTX_BTS~PREPROCESSING
Related business requirement: Before the call of the product engine/completion of the BTX, the data from
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved. 33
Method: /PM0/IF_ABP_BPU_BTX_BTS~PREPROCESSING
the persistent data containers must be loaded in the business object and subsequently calculated.
General purpose/use
of superclass method
The implementation of the method processes the business transaction until the
call of product engine.
The methods:
process_enter_btx_data()
depending on the flag: process_enter_charge_data()
depending on the flag: process_enter_comdiff_data()
/pm0/if_abp_btx_process~calculate()
/pm0/if_abp_btx_process~get_predate_trigger
of BTX API are executed here.
For Change Tariff Variant this method is called in work step 70
(/PM0/CL_ABP_BTSWS_BPA_PREPROC) of BTS ID BPA_TVR_AMD.
Method: /PM0/IF_ABP_BPU_BTX_BTS~SETUP
Related business requirement: Set up of business transaction in background mode.
General purpose/use
of superclass method
The implementation of the method sets up the business transaction context.
The method: /pm0/if_abp_btx_tech~setup() of BTX API is executed here.
For Change Tariff Variant, this method is called in work step 30
(/PM0/CL_ABP_BTSWS_BPA_SETUP) of BTS ID BPA_TVR_AMD.
4.1.3 Business Components and Business Functions
There are five major spots/points of time where a business transaction typically has to process its specific business
functions:
Checks for availability and executability of a business transaction; this issue is covered in the description of
methods /PM0/IF_ABP_BTX_CHK_ACCESS~IS_AVAILABLE and
/PM0/IF_ABP_BTX_CHK_ACCESS~IS_EXECUTABLE in section API Class of Business Transaction.
Checks and derivations at the start of a business transaction (point of time INIT; called in
/PM0/IF_ABP_BTX_PROCESS~INIT)
o Business functions called here (and elsewhere) are usually methods of one or more business components that
are customized here:
34
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
Recommendation
When creating a new business transaction, it should be considered if a new business component for the
business transaction makes sense.
o For shipped business transactions, the shipped business functions are called in an implementation of the BAdI
/PM0/ABP_PROC_DERIVE_BADI. Change Tariff Variant here has the implementation
/PM0/ABP_PROC_TVR_BADI. Look up in the implementing class /PM0/CL_IM_ABP_PROC_TVR_BADI what
business functions are called at the start of Change Tariff Variant.
o For shipped business transactions, partners and customers can implement additional checks by implementing
the multi-implementable filter BAdI /PM0/ABP_PROC_DERIVE_CUST_BADI for the business transaction.
o For a partner- and customer-owned business transaction, you have some options as to how to implement the
checks and derivations in /PM0/IF_ABP_BTX_PROCESS~INIT. In any case, it is recommended to collect all
checks in new business functions as <BTX specific business component>->do_checks_init. Here, you can also
call business functions that are already shipped.
Checks and derivations when completing/calculating a business transaction (point of time END, called either in
/PM0/IF_ABP_BTX_PROCESS~PRE_FINISH for non-calculating business transactions or in
/PM0/IF_ABP_BTX_PROCESS~CALCULATE for calculating ones)
o For shipped business transactions the shipped business functions are called in an implementation of BAdI
/PM0/ABP_PROC_DERIVE_BADI. Change Tariff Variant here has the implementation
/PM0/ABP_PROC_TVR_BADI. Look up in implementing class /PM0/CL_IM_ABP_PROC_TVR_BADI what
business functions are called at completion of Change Tariff Variant.
o For shipped business transactions, partners and customers can implement additional checks by implementing
the multi-implementable filter BAdI /PM0/ABP_PROC_DERIVE_CUST_BADI for the business transaction.
o For a partner- and customer-owned business transaction, you have some options as to how to implement the
checks and derivations in /PM0/IF_ABP_BTX_PROCESS~ PRE_FINISH/CALCULATE. In any case, it is
recommended to collect all checks in new business functions as <BTX specific business component>-
>do_checks_end. Here, you can also call business functions that are already shipped.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved. 35
Check if the completion of business transaction is allowed (called Check for Change here)
o The purpose of this business function is to determine by comparing the new state of the application
(determined in /PM0/IF_ABP_BTX_PROCESS~PRE_FINISH) with the old state (determined in
/PM0/IF_ABP_BTX_PROCESS~INIT) if relevant fields from a business perspective have been changed. Here
you can define the fields that have to be changed in order to complete the business transaction.
o For Change Tariff Variant, for example, the shipped business function /PM0/CL_ABP_BC_PRC_POLPR->
/PM0/IF_ABP_BC_PRC_POLPR~TVR_AMENDMENT_CONCL_ALLOWED ensures that the value of the tariff
variant field needs to be changed before the business transaction can be completed.
o For shipped business transactions, the enhancement spot /PM0/ABP_AMD_CHECK_ES offers a BAdI for
each business transaction where partners and customers can implement their own checks for change. In the
case of Change Tariff Variant, this is the BAdI /PM0/ABP_TVR_CHECK_BADI.
o For partner- and customer-owned business transactions, the implementation of a check for change is not
strictly mandatory, but recommended. For this purpose, we recommend creating a business function <BTX
specific business component>->CHECK_AMENDMENT_CONCL_ALLOWED.
Completion service (also frequently referred to as conclude service): A service class that orchestrates the detail
tasks for completing a business transaction (prepares and performs the call of the product engine, determines the
journal entry to be written…)
o Customizing a completion service class for a business transaction is mandatory
o The Customizing of completion services is done here:
o There are many shipped, general completion service classes that meet most of the expected needs. For a new
business transaction, first check if you can use one of these superclasses or find the suitable one to inherit
from a copy of it.
Note
If a business transaction is executable at policy level, you have to maintain an entry for the line of business =
initial for that business transaction.
36
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
o The Customizing of the completion service is described in more detail in Customizing of Completion Service.
4.1.4 Data Container and Filler Classes
4.1.4.1 Basic Principles
What is the purpose of data containers and filler classes?
As of FS-PM 5.0, the background processing of business transactions is done as the execution of a BTS date that must
have been scheduled beforehand.
When planning the background execution of a BTX, the maintained data has to be stored in a persistent manner. This
is done in special data container database tables, of which /PM0/ABDCPOLPR is an example where contract data is
stored. The data container classes represent the data access layer here. The data container class for Change Tariff
Variant is /PM0/CL_DC_SVC_TVR_CON, for example.
When scheduling a background business transaction, for instance through the Mass Change business process or a
BTX interface, the data container stores the data entered in the data container tables.
When executing the business transaction in background mode, the data is loaded from a data container instance
into the API of the business transaction. For this to work, the business transaction and data container have to
agree to use the same interface here, and also on call of the BTX DC interface. For Change Tariff Variant, this BTX
DC interface is /PM0/IF_ABP_BTX_TVR_CON, which is implemented by data container
/PM0/CL_DC_SVC_TVR_CON and, of course, used by /PM0/CL_ABP_BTX_TVR_MASTER.
When a reversed business transaction is reimplemented, the effective date of a BTX is shifted, the BTX data is revised,
or a postdated business transaction is resolved, this BTX is processed in background mode. This means that the input
data for the BTX has to be supplied by a data container in these cases. The business transaction has already been
executed, either postdated or regularly in the first three cases. So the data maintained in the original execution of the
business transaction is already stored somewhere in the application database tables of Policy Management. To be able
to use a unified way of background data processing through the BTX DC interface, filler classes were introduced. These
determine the data from the application tables and load it into the data container instance. If the effective date of the
BTX is shifted, filler classes also have to change the data of the original execution before transferring it to the data
container. All duration fields have to be adjusted to the new effective date. For Change Tariff Variant, the filler class is
/PM0/CL_RDO_DC_TVR_GET. It implements methods /PM0/IF_ABP_RDOPD_DC_GETTER~GET_DC_REDO for filling
the data container for reimplementation, /PM0/IF_ABP_RDOPD_DC_GETTER~GET_DC_SHIFT for the shift of
effective date and revision of BTX data, and /PM0/IF_ABP_RDOPD_DC_GETTER~GET_DC_PREDAT for resolving
postdating.
Caution
Filler classes determine all application table changes assigned to a BTX as relevant input data for the DC. If an
editable entity was added by the user and/or by the system during calculation or derivation, this entity would
be considered as input data for the DC. This means that the filler classes would fill the DC with data, which was
NOT only originally maintained by the user. In such a case, the implementation has to ensure that, during the
reimplementation or resolving of a postdated business transaction, this entity would not be transferred to the
DC, otherwise the calculation or derivation in the BTX will not run again.
FS-PM provides a wizard for generating the filler classes. In partner and customer systems, the wizard can also create
an enhancement implementation of the BAdI /PM0/ABP_TRANSFER_CSTM_BADI, which is required to handle
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved. 37
entities and fields that are not owned by SAP. The use of the wizard requires that all control parameters of the BTX are
maintained in Customizing.
Detailed information on how to use the wizard is available in the online documentation of the wizard. The wizard for
generating the filler classes is available in the developer Customizing area /PM0/CUST_INT:
The interaction between the business transaction and data container is explained in the following two sequence
diagrams:
38
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
Figure: Regular processing of a data container by a BTX
In general, the input of the DCs is generated by a user who enters data in a UI. This data is then stored in a database
(DB) table. The DC fetches the data from the DB table and is used by the BTX to retrieve the fetched data.
Figure: Processing of a DC by a BTX in reimplementation/postdating/shifting effective date/revising BTX data
The processing of the BTX that uses the data container is unchanged compared with the schema previously shown,
and it is an example for the already mentioned separation of data processing and data retrieval. In the case of
reimplementation/postdating, the data that has to be entered is already stored in the application tables of Policy
Management, and it has to be fetched and transferred to the data container. These actions are executed through DC
filler classes. These classes are BTX-specific classes that retrieve the requested data from the database tables and set
them into the corresponding DC.
The following two paragraphs provide some more details on data container issues:
The BTX defines an interface that contains GETTER and SETTER methods for the entities that the BTX is able to
process. A distinction of the possible actions that the BTX can perform on the entity is given in the method
signature, in other words, one has parameters that create, update or delete the entity. This interface is called the
BTX DC interface. The background of the separation of the data retrieval and processing is based on the fact that
the BTX itself must not have any knowledge about the source of the data; it only has to process the data. The BTX
is not responsible for filling the DC with data; it only has to retrieve the data from the DC and process it according
to the business logic of the BTX.
The BTX DC interface is implemented by a DC. This implementation contains the algorithm to get the necessary
data and return it to the caller. The DC can either realize its own algorithm to retrieve the requested data or it can
be filled from “outside”. As a consequence of the possibility to fill the data container by an external caller, the DC
implements a second interface, the DC SETTER interface that allows the caller to store the data (including the field
modifier information). The DC setter and the BTX DC interface should be in sync concerning the data that can be
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved. 39
stored. Nevertheless they certainly differ with regard to the concrete signatures (for example, data types) and the
implementation of the interfaces.
As a second obvious consequence, different DC classes are available. They differ not only with respect to the BTX
but also with respect to the context in which they are used. The different contexts can be seen within the type of
the data containers (see tables /PM0/ABP_BTX_CT and /PM0/ABP_BTXCCT).
The two most prominent types are GRU_SA and SVC_API. The DCs behind the GRU_SA are relevant for use in the
Mass Change business process. The DCs of type SVC_API are designed to be suitable for all other users.
As of FS-PM Release 5.3, a new data container type MAPBOX is required for service-enabled business
transactions. For details, see Service Enablement of Change Process and Business Transactions.
4.1.4.2 Customizing
Once the repository objects are created, these have to be customized in the developer Customizing area
/PM0/CUST_INT in the activity Configure Control Parameters for Business Transactions:
Figure: Structure of the activity Configure Control Parameters for Business Transactions
The following views within this activity are relevant in the context of data containers and filler classes (aspects
regarding enhancements by partners or customers are covered in the next paragraph):
Business Transaction / Data Container Categories and Classes: Assigns to a BTX data container categorie, data
container classes and DC SETTER interface – Maintained by SAP/partner only.
Data Container Categories, Entities, and LoBs: Defines for a business transaction/data container category the
entities that can be processed and the underlying database table for persistent DC's – Maintained by
SAP/partner only.
Data Container Categories and Classes (Customer): Assigns to a BTX data container categories, data container
classes and DC SETTER interface – For use by customers.
Data Container Categories, Entities, LoBs (Custmr): Defines for a business transaction/data container category
the entities that can be processed and the underlying database table for persistent DC's – For use by customers.
Lines of Business: Defines the lines of business for which a business transaction is available – For use by SAP,
customers.
40
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
Note
For a business transaction to be available at policy level, you have to enter line of business = ‘BS’ here (stands
for Basis; at policy level, no line of business can be determined). In all other cases, you have to name each LoB
explicitly. ‘BS’ does not mean that a BTX is available for all LoBs, but it is available at policy level. For instance,
if a BTX is available at policy level and at contract level, it is necessary to customize ‘BS’ and each LoB like ‘LL’,
‘LP’, and so on.
Entities and Operations: Here, for each business transaction/line of business, the entities (DB table name) are
defined that can be processed, and for each such entity the permitted operation modes – Maintained by
SAP/partner only.
Example
In this view, all the entities with input fields on the corresponding business transaction UI need to be
maintained. Additionally, you have to specify the operations that can be performed by a user for this entity:
creation, modification, or deletion. It is also possible to define a subprocess that ensures that the entity is
processed by a subprocess in background mode.
o Input Fields: Defines, for each business transaction/line of business/entity, the maintainable fields –
Maintained by SAP/partner only.
o Input Fields Standard Entity (Customer): Defines, for each business transaction/line of business/ shipped
entity, additional maintainable fields owned by the partner or customer – For use by customers. You can
add fields here for shipped entities without need for modification.
o Entities and Operations (Customer): Here, for each business transaction/line of business, the entities (DB
table name) owned by the partner or customer are defined that can be processed, and for each such
entity the permitted operation modes – For use by customers. You can add entities here for shipped
business transactions modification-free.
o Higher-Level Entities/Higher-Level Entities Standard Entity (Customer):
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved. 41
Example
In this view, you can enter all the possible parent entities for an input entity. For example, in the case shown
above, the entity ALDAPREM is a valid input entity only if it is a direct child of the coverage. If higher-level
entities are maintained, background processing should raise an error message if the input data is not
consistent with this Customizing.
o Output Entities/Output Entities (Customer): If you use UIs other than SAP GUI, for instance Web Dynpro
based on Floor Plan Manager, you might need to specify from which entities you need to get data for
display only. This can be done in these views.
o Input Fields (Customer): Defines, for each business transaction/line of business/partner- or customer-
owned entity, the maintainable fields – For use by customers.
o Filler Classes: Defines the filler class for a business transaction – Maintained by SAP/partner only.
o Filler Classes (Customer): Defines for a business transaction the filler class – For use by customers.
4.1.4.3 Overview of Enhancement Activities for Partners and Customers
Only enhancement activities in the context of data containers/fillers are described here. For further information, refer
to the FS-PM Enhancement Guide.
Enabling shipped business transactions for maintaining partner/customer-owned fields in shipped entities
Maintain the Customizing activity Input Fields Standard Entity (Customer)
If required maintain the Customizing activity Higher-Level Entities Standard Entity (Customer)
Implement the following BAdIs:
o /PM0/ABP_DC_CHECK_BADI
o /PM0/ABP_DC_COMPARE_BADI
o /PM0/ABP_DC_MERGE_BADI
o /PM0/ABP_DC_INIT_BADI
42
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
o /PM0/ABP_TRANSFER_CSTM_BADI
Enabling shipped business transactions to maintain additional partner-/customer-owned entities
Create a new data container class; this one should delegate handling of the shipped data container to the shipped
data container
Maintain the following Customizing activities under Business Transaction Control Parameter:
o Data Container Categories and Classes (Customer)
o Data Container Categories, Entities, LoBs (Customer) if needed
o Input Fields (Customer) and Higher-Level Entities (Customer) if needed
If, for a shipped business transaction, a customer-owned data container is customized, this one will be used
instead of the shipped one.
Create new filler class and maintain the Customizing activity Filler Classes (Customer). If, for a shipped business
transaction, a filler class is customized, this one will be used here instead of the shipped one.
Enabling a new partner- or customer-owned business transaction for background processing
Create data container classes and filler class
Maintain the following Customizing activities under Business Transaction Control Parameter:
o Data Container Categories and Classes (Customer)
o Data Container Categories, Entities, LoBs (Customer)
o Input Fields Standard Entity (Customer)
o Higher-Level Entities Standard Entity (Customer)
o Entities and Operations (Customer)
o Input Fields (Customer)
o Higher-Level Entities (Customer)
o Output Entities (Customer)
o Filler Classes (Customer)
4.2 PBT Models
4.2.1 Process Model for Business Transaction
This chapter does NOT describe specific issues for process models of subprocesses. We assume that you are familiar
with Customizing process models in PBT.
Cross-application commands
For each business transaction to be executable in dialog mode, you have to create a cross-application command and
assign it to the process model of the BTX in PBT Customizing.
For a business transaction that shall be reimplementable in semi-automatic mode, you have to define an additional
cross-application command.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved. 43
Example
Figure: Cross-application command for regular execution of Change Tariff Variant in dialog mode
Figure: Cross-application command for executing Change Tariff Variant in semi-automatic reimplementation
In the examples above, the commands CMD_A_TVR_AMD and CMD_A_TVR_REDO are assigned to the process model
P_B_S_TVR_AMD that implements the business transaction Change Tariff Variant.
Caution
Both commands are assigned to the same process model, but for the command for reimplementation of the
business transaction you have to mark the checkbox Submodel.
44
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
Attributes of process model
Example
Figure: Attributes of process model P_B_S_TVR_AMD
The following attributes have to be maintained for a business transaction process model:
Process Model: the name given here is the technical BTX_ID
Description
Command on Entry: CMD_M_ON_ENTRY. The successor of this command is the first model node to be processed
in dialog mode
API class: here the API class described in API Class of Business Transaction has to be entered
BTS API class: here the BTS API class described in API Class for Executing a Business Transaction in Background
has to be entered
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved. 45
Process model nodes
Example
Figure: Process model nodes of process model P_B_S_TVR_AMD
All nodes either implement
Subcontroller models or system dialogs (the P_B_D-nodes), or
Methods of the BTX API class (the P_B_P-nodes), or
Process models of subprocesses (the P_B_S-nodes), or
Exit commands that are returned to the caller when leaving the process model (the P_B_E-nodes)
Recommendation
For partners or customers implementing their own business transaction, we recommend adhering to the
naming convention as outlined above. For implementing a business transaction, we also recommend to copy a
suitable shipped process model and performing the required adjustments in your copy.
46
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
Recommendation
When customizing the PBT process model, make sure that the commands used to find the successor nodes
are consistent with the commands returned by the methods of the business transaction API class or by used
submodels. This will avoid a lot of error analysis.
In the sample model P_B_S_TVR_AMD, not all customized nodes are mandatory for any BTX:
Alternative commission participant: The nodes P_B_P_CMDIFF_DEL, P_B_P_EXIT_COMDIFF,
P_B_P_PREP_CMDIF_ADD, P_B_P_PREP_CMDIF_MOD and P_B_S_COMDIFF_DETAIL are required only if your
business transaction shall be able to handle an alternative commission participant. This is the case for Change
Tariff Variant. /PM0/CL_ABP_BTX_MASTER offers the methods to be implemented by these nodes.
Call of product engine/insurance mathematics: The nodes P_B_P_CALCULATE and P_B_P_CALC_RES are
required only if your business transactions need to call the product engine. This is the case for Change Tariff
Variant.
Simulative calculation: The node P_B_P_CALC_DLG is required only in case your business transaction shall offer
the button for simulative calculation in dialog mode. This is the case for Change Tariff Variant
Display/maintenance of coverage details: the nodes P_B_P_PREP_COV_DET and P_B_S_COV_DET are required
only if your business transaction shall be executable at contract level and offer display or maintenance of data for
the included coverages. This is the case for Change Tariff Variant.
It is probably useful to check which BTX API methods are implemented by which node.
4.2.2 Subcontroller Model
This chapter does NOT describe the creation of subcontroller models in detail. We assume that the reader is familiar
with Customizing of subcontroller models in PBT. For instance, the meaning and Customizing of views and ALV
parameters is not explained in this document.
Besides the generally valid and reusable system dialogs, such as in the subprocess of reversing a business transaction,
a business transaction usually has a specific dialog where the business data relevant for the business transaction are
maintained. Thus, a process model of a business transaction commonly has a node which implements the
subcontroller model.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved. 47
Example
Figure: The process node P_B_D_TVR_MOD in process model P_B_S_TVR_AMD implements the subcontroller model
P_B_D_TVR_MOD
The subcontrollers, also referred to as process contexts, control the data transfer between the channel layer (ABAP
Dynpro in the shipment) and the BO layer. Each node in the subcontroller model should implement a process context.
48
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
Example
Figure: The nodes of the subcontroller model Change Tariff Variant (P_B_D_TVR_MOD)
The standard nodes are:
P_B_MDIA01
P_B_NAVTREE
P_B_HEADER
P_B_LOGGER
If there is a tabstrip, following nodes have to be included:
P_B_TAB01 – to capture the tabstrips
P_B_SCRN01 - P_B_SCRN0X – for the tabstrips themselves.
Basic settings of subcontroller model
If the dialog of the business transaction is to display a button for simulative calculation, in Screen Assignment you
should enter GUI status BTX_AMENDMENT_CLT_2 of function group /PM0/SAPLABP_CDM_GUI_STATUS (or
BTX_AMENDMENT_REL if the business transaction is to be able to release the application from the business
transaction dialog). If not, then use GUI status BTX_AMENDMENT_ENTRY (or BTX_AMENDMENT_ENTREL if the
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved. 49
business transaction is to be able to release the application from the business transaction dialog) of the same function
group.
The following attributes of the main node P_B_MDIA01 have to be maintained (e.g. P_B_D_TVR_MOD):
Dialog Model: name of the dialog model
Channel ID: name of the node, in this case P_B_MDIA01
Description: placeholders (&1 for name of business process, &2 for name of BTX) that are filled at runtime to
display the GUI title
Process Context
Process contexts of subcontroller model
As mentioned above, each node in a subcontroller model should implement a process context.
Example
Figure: Attributes of process context P_B_MAIN_DYNPRO
The following attributes of the process context have to be maintained (e.g. P_B_MAIN_DYNPRO):
Process Context: the name of the process context
Description
Class Name (of subcontroller class)
Lifetime (for instance, persistent, non- persistent, cross-mode persistent; usually the instances of a process
context have to live as long as the dialog is loaded, so cross-model persistence is the most common choice here
The Attribute field has to be maintained if it is a process context that handles data transfer between channel layer
and business object
For all kinds of dialog nodes (Main Dynpro, Tabstrip, Screen, Section, View, ALV), process contexts, subcontroller
classes, and screen controller classes are shipped that can be reused in many cases.
Recommendation
When implementing a new process context for transferring data to views or ALVs it, should be checked first if
the generic subcontroller classes /PM0/CL_ABX_BPS_U_VIEW1 (for views) or /PM0/CL_ABX_BPS_U_ALV1
(for ALVs) fulfill the requirements and can be used.
50
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
Caution
When you have more than one dialog node on one screen that access the same entity of the business object,
you have to maintain the screen controller /PM0/CL_3F_CDM_SCRGROUP_CTRL for these nodes.
4.3 Internal Customizing
4.3.1 Customizing of Control Parameters of a Business Transaction
Here the views of the activity Control Parameters of a business transaction are described that have not yet been
covered in Customizing.
Once the repository objects are created, these have to be customized in the developer Customizing area
/PM0/CUST_INT in the activity Business Transaction Control Parameter:
Figure: Structure of activity Business Transaction Control Parameter
Initial Screen: Control Parameters
In the following figure, the maintained entries for the shipped business transaction Change Tariff Variant are displayed:
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved. 51
Example
Explanation of attributes:
Business Transaction: Unique identifier for a business transaction; for business transactions owned by partners or
customers, the PBT process model of the business transaction has to be maintained here. For customers, the
namespaces 9*, Y* and Z* are reserved. Partner entries should start with a ‘/’.
Name of BusTrans / Bus. Trans. Descr.: Here you can assign a short and a long name for your business
transaction; this should be consistent with name of corresponding PBT model.
Execution Level: Here you can define at which execution level(s) a business transaction shall be available; Change
Tariff Variant, for instance, is available at contract level only. The definitions made here are crucial for the
availability of a BTX for a template in IFBC, for instance: The business transaction is only available for a certain
template if the corresponding execution level is selected here.
Caution
Simply selecting checkboxes here does not enable the BTX to run at the selected levels. The technical
implementation of the business transaction must support the executability at the chosen levels. This
statement also applies to most of the other Customizing described in this section.
Note
For business transactions that are an inclusion of main axis elements, the level of the parent main axis node
also needs to be customized as an execution level.
Processing Level/Subprocesses – Cov.Detail Process.: This checkbox is to be set if your business transaction is
available at levels higher than coverage but offers maintenance of coverage data by coverage detail views.
52
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
Processing Level/Subprocesses – Subcov.Detail Processing: This checkbox is to be set if your business
transaction is available at levels higher than subcoverage but offers maintenance of subcoverage data through
subcoverage detail views.
Processing Level/Subprocesses – Sched.Higher ExecLvl: For scheduling background execution of main axis
inclusion business transactions, the BTX is scheduled to be executed at parent level. So this checkbox has to be
selected for main axis inclusion business transactions.
Processing Level/Subprocesses – Tax Relevance BTrans: If a business transaction can be subject to taxation
handling, this checkbox has to be selected.
Processing Level/Subprocesses – Charges Relev.BTrans: This checkbox has to be marked if you want to be able
to collect charges for the business transaction.
Processing Level/Subprocesses – Diff. Comm.Paticipnt: Select this checkbox if a business transaction is to be
able to maintain alternative commission participants.
Metainformation – Single Exec. (SAP): SAP-owned checkbox that determines if a business transaction is
executable only once in one business process.
Note
If single execution for a BTX is maintained here you cannot allow multiple execution in the Customizing activity
Define Business Transactions (see also Customizing of Business Transactions).
Metainformation – Display Only: With this checkbox you can determine if a business transaction is for display
only; if set, no data can be entered in dialog mode.
Metainformation – Validity BT PE: this checkbox is to be marked if the business transaction shall be available on
facultative product elements. Commonly used for main axis inclusion business transactions.
Metainformation – Postdating Possible: this checkbox is to be set in case the business transaction is enabled for
postdating
Metainformation – Subj. to Postdating: This checkbox is to be set in case the business transaction can actively
raise postdated status of application. If postdating is actually raised depends on implementation of BAdI
/PM0/ABP_BTXPREDCHK_BADI.
Metainformation – Background BT: mark this checkbox in case a business transaction can ONLY be executed in
background
Metainformation – Reimplement: mark this checkbox in case a business transaction can be (semi-automatic or
automatically) reimplemented in case of being cancelled by an out-of-sequence change. For additional
Customizing relevant in the context of reimplementation, see Customizing of business transactions.
Metainformation – BTrans CoInsurance and BTrans Coll./Grp.Ins: Select one or both of these checkboxes if the
business transaction is to be available in the Mass Change business process.
Caution
Availability in the Mass Change business process requires a special, additional implementation for a business
transaction. For shipped business transactions that are available in the Mass Change business process, this is
done by the *EDC models. For the Change Tariff Variant, these are the PBT process model P_B_S_TVR_EDC
and subcontroller model P_B_D_TVR_EDC. For more details, refer to these.
Metainformation – BTrans Coinsurance/Coll.GrpIns.: As shipped, the Mass Change business process offers the
modes Coinsurance and Collective Insurance/Group Insurance; if the business transaction is available for the
Mass Change business process, select with these checkboxes the mode(s) of the Mass Change business process
where the BTX shall be available.
Metainformation –Relevant for Updating relevant: In this field, you can maintain the update relevance of a business
transaction.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved. 53
Caution
Up to FS-PM 5.0, we offered the mode “only non-update-relevant changes” in the Change business process to
increase performance in some scenarios. But this is a possible cause of severe errors. Therefore, as of FS-PM
5.1, all business transactions are regarded as being update-relevant. Thus the standard no longer
differentiates between update-relevant and non-update-relevant business transactions. Hence the Relevant
for Updating attribute is now obsolete in the standard delivery. If you nevertheless want to make any functional
use of this attribute, you have to do so in a partner or customer development.
Metainformation – Cross-LoB: In this field, you can specify whether a business transaction is designed for a single
line of business or for all lines of business.
Technical Parameters – API Class: Here you maintain the API class described in API Class of Business
Transaction.
Technical Parameters –BTS Class: Here you maintain the BTS API class described in API Class for Executing a
Business Transaction in the Background.
Technical Parameters –BTrans Data Container IF: Here you maintain the BTX DC interface implemented by the
data container and used by the BTX API class as described in Basic Principles.
Technical Parameters – Command ID: Here you maintain the cross-application command for the BTX in dialog
mode as described in Process Model for Business Transaction.
Technical Parameters – Command BT Reimplement: Here you maintain, for reimplementable business
transactions, the cross-application command for the BTX as described in Process Model for Business Transaction.
Technical Parameters – DC Interface: Data container interface for setting the data in a data container instance.
Technical Parameters – DC Interface cannot be generated: For internal use by SAP only.
View: Business Processes
Example
Figure: Assignment of Business Processes to Change Tariff Variant
In this view, you can assign business processes that are maintained in table /PM0/ABUUBIZPRO to a business
transaction. In the above example, Change Tariff Variant is available in in the Change business process only.
54
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
Note
The assignment of business process(es) to a BTX here is crucial for the BTX Customizing in IFBC (see In-Force
Business Configurator): A business transaction is available for a template for a certain business process only if
that business process is assigned to the BTX in this view.
View: Interfaces
Currently only used internally by SAP
View: Processing IDs
Example
Figure: Assignment of Processing IDs to Change Tariff Variant
In this view, you should assign all possible processing IDs/journal entries that can be written by a business transaction.
It is currently for information only here, but SAP recommends maintaining these entries.
Note
The processing IDs to be maintained here first have to be entered in the Customizing of journal entries, see
Defining Journal Entries.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved. 55
4.3.2 Customizing of Control Parameters of Subprocesses
The structure of this activity is similar to that of the control parameters of a business transaction. Here you maintain all
the subprocesses with user input, for example the subprocesses to capture detailed data for lateral objects, such as
clauses. Based on this information, the background processing methods for the subprocess API can be generated by a
wizard. For more information, see the online documentation provided by the wizard and General Comments On How to
Implement a Business Transaction.
4.3.3 Customizing of Completion Service
The terms 'Completion Service' and 'Conclusion Service' are synonyms in this document.
Figure: Completing a business transaction
When you click the Complete button in each business transaction (or when this step is automatically performed during
background processing of business transactions), some special actions are carried out, such as:
Calling the product engine/insurance mathematics after providing information on fund prices, taxes and charges,
for example
56
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
Retrieving the changes requested by the product engine/insurance mathematics and adjusting the application as
well as accounting or tax information accordingly
Reacting to errors arising during communication with the product engine
Checking whether the premiums have changed due to the completion of the business transaction, as this is often
relevant for taxation issues
Informing components, such as tax and charges, about the performed changes
Determining which journal entry is to be written
Although not every business transaction needs all of these steps during its completion, the order of performing these
tasks is the same for all business transactions.
Many of these tasks are similar for all business transactions, or at least for business transaction assigned to the same
line of business, or with similar properties.
Therefore the Completion Service serves as a central point of access for the completion of a business transaction.
Its behavior matches the known behavior of business functions:
At certain predefined points in time the application calls methods of the Completion Service, providing information
such as line of business and business transaction ID.
At run time, Customizing is read and, within this Customizing, based on the information provided, the concrete
implementation class is determined and called.
The Customizing for the Completion Service can be found with transaction SE43 under Developer Customizing ->
Internal Customizing:
Figure: Where to customize the Completion Service class for a business transaction
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved. 57
As in many cases, even the coding itself does not differentiate for business transactions with similar properties. A class
hierarchy is provided that covers coding that is required for many cases.
The figure below illustrates this class hierarchy with regard to LoB-dependent implementations:
Figure: Class diagram of hierarchy of Completion Service classes
Explanation of German notation:
Fassade der Fachfunktion: Façade of the business component
Lebenimplementierung ohne VT: Implementation for LOB Life without call of product engine
Lebenimplementierung mit VT: Implementation for LOB Life with call of product engine
Lebenimplementierung mit VT und Fonds-Spezifika: implementation for LOB Life with call of product engine and funds-
specific functions
Basisimplementierung: Cross-LOB superclass implementation
SHU-Implementierung ohne VT: Implementation for LOB P&C without call of product engine
SHU-Implementierung mit VT: Implementation for LOB P&C with call of product engine
58
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
As for business functions, access to the Completion Service is by way of a façade,
/PM0/CL_ABP_BC_BTXCONCLUDE_SRV in this case. This provides access to the methods of interface
/PM0/IF_ABP_BC_BTXCONCLUDE_SRV, which can be used for the process classes of the business transactions.
The basic implementation of the methods is defined in class /PM0/CL_ABP_BC_BTXCONCL_BASE.
This implements interface /PM0/IF_ABP_BC_BTXCONC_IM_BASE, together with
interface/PM0/IF_ABP_BC_BTXCONCLUDE_SRV, which allows a more finely granulated breakdown of steps to be
performed before and after the call of insurance mathematic. The basic implementation of these interfaces contains
the steps required for the P&C/Non-Life LoB (required processing steps for the Tax and Charges components before
and after the call of insurance mathematics).
A crucial point is the CALL_IM method, for which an empty implementation is provided. It is used to define the actual
business transaction-specific call of insurance mathematics.
The Life implementation /PM0/CL_ALP_BC_BTXCONCL_LL and its P&C/Non-Life counterpart implementation
/PM0/CL_APP_BC_BTXCONCL_LP, are derived from the basic implementation. These classes also do not implement
the call of insurance mathematics. The reason for this is that not all business transactions within these lines of
business require an insurance mathematics call. Nevertheless, these two LoB-dependent implementations (or
derivations thereof) ensure a central determination, for instance of the journal entry that is written.
The last level of this construction is provided by the classes /PM0/CL_ALP_BC_BTXCONCL_IM_LL and
/PM0/CL_APP_BC_BTXCONCL_IM_LP, which are the starting point for all completion implementations containing an
insurance mathematics call.
As a special feature, class /PM0/CL_APP_BC_BTXCONCL_IM_LP implements method CALL_IM with the call of
insurance mathematics method CALL_PCMODCONTRACT, which is frequently required in P&C/Non-Life.
Class /PM0/CL_ALP_BC_BTXCONCL_IM_LL also implements interface /PM0/IF_ABP_BC_BTXCONC_IM_LL, which
contains additional Life-specific methods for the insurance mathematics call.
For both classes, the reference to the LoB-dependent adapter implementation is defined in a member attribute.
A further implementation, /PM0/CL_ALP_BC_BTXCONCL_FUND, is available for fund processing, which is a
derivation of class PM0/CL_ALP_BC_BTXCONCL_IM_LL, to centrally define general fund product-specific steps.
Recommendation
Recommended procedure for implementing a Completion Service for a new business transaction
1. First you should determine the properties of your business transaction with respect to its line of business, the
necessity for communication with insurance mathematics, and its relation to funds.
2. Through this analysis you determine which of the classes of the class hierarchy best matches your requirements.
Example
The call of insurance mathematics is required for business transaction "Change Tariff Variant" in the P&C line
of business. The chosen class is therefore /PM0/CL_APP_BC_BTXCONCL_IM_LP.
3. Now you should check whether the implementation of this class matches the requirements of your business
transaction. If this is the case, you can just enter this class in the Customizing of Completion Service for your
business transaction. Proceed with step 7.
4. If it is not possible to use one of the delivered classes, proceed with step 5.
5. Copy your chosen class (and the delivered superclasses of your chosen class) to create your own class hierarchy
in your namespace.
Caution
The partner or customer Completion Service should not inherit from /PM0/ classes.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved. 59
6. Create your own class that inherits from the copy (created in step 5) and reimplement the methods for which the
superclassmethods do not match your requirements.
7. As in Implementation of a Business Transaction – Overview of Major Steps, you already determined which journal
entries are to be written (Question: Which journal entries shall be written by the business transaction?), you can
enter those journal entries (proc_ids) in Customizing.
Caution
The journal entries first have to be maintained in Customizing before they are entered here (Customizing view:
Define Journal Entries, see Defining Journal Entries).
If the journal entry can only be determined at run time, the method DETERMINE_JOURNAL_ENTRY needs to be
reimplemented.
8. If the business transaction has no fund relation, enter NFBTX as "Unit-Linked Processing". In other cases, enter
the "Unit-Linked Processing" you require in this line.
Caution
This UNIT-LINKED PROCESSING must also be maintained in Customizing of Fund Management (Customizing
view: Define Unit-Linked Processing), as well as being considered in the "FUND/ORDER-Service" business
component (class /PM0/CL_ALP_BCFUNDORDER_SRV_LL).
Caution
When creating a new entry for a completion service, ‘320‘ always has to be entered as the business
component ID.
For the implementation of your own Completion Service classes, the following methods are of special importance and
are therefore listed:
CALL_IM
General purpose Implement the call of insurance mathematics by determining the correct (LoB-
dependent) shell and calling the method either synchronously (results are
directly written back to the business object) or asynchronously.
If the calculation base is missing the "predating handler" is to be set to
PREDATED.
In case of synchronous calls, the accounting component and tax component are
called to retrieve the call's result.
Example
For Change Tariff Variant, in line of business LIFE, the method
call_constrecal is called after retrieving data containers for tax,
accounting component, and funds within class
/PM0/CL_ALP_BC_CNCLD_TVRAMD.
60
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
HANDLE_IM
General purpose In case of asynchronous calls, the results of the call need to be written back to
the business component by calling the specific method of the (LoB-dependent)
shell.
In case the calculation base is missing the "predating handler" is to be set to
PREDATED.
In case of asynchronous calls, the accounting component and tax component
are called to retrieve the call's result.
DETERMINE_JOURNAL_ENTRY
General purpose In case the journal entry can only be determined at run time, the determination
has to be implemented within this method.
Example
For the Change Benefit/Premium business transaction, the journal entry
is different depending on the premium increasing or decrease, therefore
this check is implemented in /PM0/CL_ALP_BC_CNCLD_CHGBNF-
>DETEMRINE_JOURNAL_ENTRY.
COLLECT_FUND_DATA
General purpose Required fund prices are determined and stored in the fund data container.
Example
For the Additional Deposit business transaction, the fbtx_id is
determined (Customizing is read) and the business function
"prepare_fundsalloc_pm_call " of business component FUND/ORDER-
Services to read the prices and store them to the container is called in
/PM0/CL_ALP_BC_CNCLD_ADEP->COLLECT_FUND_DATA.
In the Customizing view itself, the following information has to be maintained:
LoB: Line of business for which the business transaction is called
Business Transaction: The ID of the business transaction
Class Name: The Implementing class of the completion service (result of step 3 or 6 in the recommendation
above)
Processing: The journal entry that is written on successful completion of the business transaction when the call is
not from a reimplementation or a postdated application (result of step 7 in the recommendation above).
ReImpl.Processing: The journal entry that is written on successful completion of the business transaction when the
call is from a reimplementation (result of step 7 in the recommendation above). This is only required if you really
want to write a specific journal entry here.
Postdated Processing: The journal entry that is written on successful completion of the business transaction on
the call of a postdated application (result of step 7 in the recommendation above).
Unit-Linked Processing: Specifies that fund-linked processing is carried out, and its type (result of step 8 in the
recommendation above).
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved. 61
Example
The entries for the "Change Tariff Variant" business transaction are:
4.4 IMG Customizing
4.4.1 Customizing of Business Transactions
Most of the Customizing activities you have to maintain after developing a new business transaction can be found
under the Customizing activity Business Transactions, Actions, and Process Steps:
Figure: Customizing activities for customizing business transactions
Here is a short description of the activities that commonly have to be maintained for a new business transaction. Some
of the above listed activities are described in other sections, depending on the context they are used.
62
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
Define Business Transactions
Example
Figure: Table entries for Change Tariff Variant
Note
The business transaction has to be maintained in internal Customizing (see Customizing of Control
Parameters of a Business Transaction) before an entry for it can be created here. Most of the information is
for display only here, and it has to be maintained in the Customizing for control parameters. Only three
checkboxes are editable here. For shipped business transactions, you can change the setting of these three
checkboxes modification-free.
o Changeable Control Parameters - ExBetContrEnd & TechEnd: You have to mark this checkbox if the
business transaction is to be executable between contract end date and technical end date
o Changeable Control Parameters - Executable on Exp. Date: You have to mark this checkbox if the business
transaction shall be executable on the expiration date of a contract element.
o Changeable Control Parameters - Single Execution: If you want a business transaction to be executable
more than once for the same contract element within a single business process, you have to deselect this
checkbox.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved. 63
Caution
This checkbox can only be deselected if the checkbox for Single Execution (SAP) is NOT selected.
Define Business Transaction Filter
In this view, you can create business transaction filters and assign business transactions to them. When you enter
such a filter in the initial screen of the Change business process, only the business transactions assigned to this filter
are available in context menu.
Define Business Transaction Sequences
Here you can define BTX sequences and assign a fixed sequence of business transactions to them. When you have
created such a sequence, you have to define the relevant parameters (availability in business processes, execution
levels, availability for lines of business) in Customizing for internal control parameters, and then assign the sequence
to the templates in IFBC, just as you would do for an ordinary business transaction.
If you start the BTX sequence in dialog mode, you are guided from one business transaction to the next (if executable)
in the sequence that is determined by your Customizing settings. Sequences defined here are not supported in
background mode.
Define Reimplementation of Business Transactions
The behavior of a business transaction in the context of reimplementation following a retroactive (= out-of sequence)
change can be customized in the Customizing activity Policy Management -> In-Force Business Management -> Basis -
> Business Transactions, Actions, and Process Steps -> Define Reimplementation of Business Transactions
(Retroactive Change).
The possible options are:
No reimplementation at all (both checkboxes not marked)
Reimplementation without user interaction (automatic)
Reimplementation with user interaction (semi-automatic)
A retroactive change always consists of at least one trigger and one processing to be reworked. The trigger of a
retroactive change can be:
One or several business transactions (as part of a business process)
An executed external date
An executed correspondence date
An executed BTS date
With regard to the processing to be reimplemented, only business transactions of the Change business process are
considered here.
64
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
Example
Figure: Behavior of Change Tariff Variant in reimplementation mode
The logic of the default implementation of the BAdI /PM0/ABP_REIMPL_RULE_BADI is as follows: The chosen settings
are valid for dialog processing as well as for background processing, while in dialog processing the settings are used as
default values for the pending reimplementations in the scheduling dialog (also sometimes called the retention dialog).
The Customizing always considers the combination of a trigger and a business transaction to be reimplemented. The
reserved word ALL can be used in each of the four fields to create generic entries. You should use this if you want to
create a setting that covers all values of the respective field or, for example, if the trigger is of no importance to you.
You have the following options to define the reimplementation of a business transaction:
1. Assignment of a certain trigger to a certain business transaction to be reimplemented (e.g. trigger business
transaction = P_B_S_XRF_AMD; reimplementable business transaction = P_B_S_TVR_AMD)
2. Assignment of an arbitrary trigger to a certain business transaction to be reimplemented (e.g. trigger business
transaction = ALL; reimplementable business transaction = P_B_S_TVR_AMD)
3. Assignment of a certain trigger to an arbitrary business transaction to be reimplemented (e.g. trigger business
transaction = P_B_S_TAXATTRIB_AMD; reimplementable business transaction = ALL)
4. Assignment of an arbitrary trigger to an arbitrary business transaction to be reimplemented (e.g. trigger business
transaction = ALL; reimplementable business transaction = ALL). The standard implementation of the BAdI
expects exactly three entries here, one entry for each trigger type.
The listed assignments can be combined. The standard implementation of the BAdI evaluates the assignments in the
order mentioned above. If several assignments match for a reimplementation, the assignment with the higher priority
is taken into account (e.g. assignment 1 takes priority over assignment 2).
You can implement the BAdI /PM0/ABP_REIMPL_RULE_BADI to realize your own evaluation of the Customizing. You
do so in Customizing for Policy Management under In-Force Business Management -> Basis -> Business Transactions,
Actions, and Process Steps -> Business Add-Ins (BAdIs) -> BAdI: Decision On Reimplementation of Business
Transactions.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved. 65
Figure: Implementation of BAdI /PM0/ABP_REIMPL_RULE_BADI
Define LoB-Dependent Settings for Business Transactions
In this Customizing activity, you determine for which business transactions and lines of business the following
processing activities are possible:
Shift Effective Date
Revise Business Transaction Data
With the "master entries" (the Business Transaction field is empty), the functions for shifting the effective date and
revising business transaction data can be generally activated or deactivated. For the Life and P&C lines of business,
the settings are already made by SAP and they cannot be changed by partners or customers. If you (as a partner)
create your own line of business, you can switch the functionality on or off for your line of business.
Figure: LoB-dependent settings for business transactions
66
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
Assign Charges Type to Business Transactions / Dates
For business transactions developed on the basis of FS-PM 5.1, this Customizing activity does NOT need to be
maintained.
Define Deactivation/Activation of Context Menu Entries
In this view, you can customize conditions (classes) that determine if the business transaction is deactivated (grayed
out) in the context menu.
Caution
As of FS-PM 5.1, this Customizing is only relevant for business transactions that are not background-enabled.
For background-enabled business transactions, these conditions are coded in the method
/PM0/IF_ABP_BTX_CHK_ACCESS~IS_EXECUTABLE of the BTX API class, as described in API Class of
Business Transaction. For instance, you do not find an entry here for Change Tariff Variant.
4.4.2 Defining Journal Entries
All processing IDs/journal entries that a business transaction is to be able to write have to be customized here:
Figure: Customizing activity for defining journal entries
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved. 67
Example
Figure: The three journal entries that Change Tariff Variant may write
For a common business transaction of the Change business process, the processing category is always PROC_T and
Prio Journal Entry is not maintained.
Note
In the above example, a special journal entry for reimplementation mode is customized. But in the standard
shipment this is no longer used. Do not forget to update the Processing IDs view in internal Customizing if you
have created new entries here.
Example
Figure: Additional information for processing ID A_PT_TARIFVAR
The additional information that can be customized here determines the relevance of the processing ID for components
and interfaces. Refer to the online documentation here for further information.
Recommendation
If a business transaction can write different journal entries, such as for postdating, the additional information
usually should be the same for all of these processing IDs. But we recommend a thorough analysis here to
evaluate the correct Customizing in case of doubt.
68
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
4.4.3 BTS Customizing
If you want to execute business transactions in the background, or if you want to resolve postdating or reimplement a
business transaction, you have to define process IDs for BTS dates. See also API Class for Executing a Business
Transaction in the Background. You can find the corresponding Customizing views in the following Customizing
activity: Policy Management -> In-Force Business Management -> Basis -> Update -> Business Transaction Scheduler
(BTS) -> Process IDs for BTS Dates
Figure: Where to define process IDs for BTS dates
These settings are essential for business transactions:
Origin ID of BTS Date: User-defined, recommended naming <BPA_XXX>
Text ID of BTS Date: User-defined
Parallel Processing Indicator: Set ‘X’ = yes
Processing via Time Model Indicator: Set ‘X’ = yes
Indicator Whether Date Removes Policy Postdating: Set ‘ ‘ = no
Business Process: Always set as ‘P‘ in the context of background execution of business transactions of the Change
business process
Business Transaction ID: btx_id of business transaction
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved. 69
Example
Figure: Definition of BTS date for background execution of Change Tariff Variant
For each BTS date, you have to define the required work steps.
These settings are essential:
ID of BTS Workstep: Sequence of the BTS work steps, which will be processed acclivitously
Class Name: Name of the class of the work step; in most cases you can use the default work steps, see example
Subphase: Necessary to split processing for the call of the product engine (at least two subphases)
Subphase 1 is for the required steps for preparation of the (possible) call of the product engine.
Subphase 2 is for the required steps after the (possible) call of the product engine.
If your BTX needs more than one call of the product engine, further subphases might be required. There is no
shipped BTX requiring more than one call of the product engine.
70
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
Example
Figure: The work steps for Change Tariff Variant
The list of work steps in the example above is the minimum set of work steps required for a business transaction with
no call or a single call of the product engine.
If the BTX executes more than one call of the product engine, you have to add the required number of subphases with
the corresponding /PM0/CL_ABP_BTSWS_BPA_POSTPROC work step.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved. 71
Example
Figure: Work steps of a business transaction with six calls of the product engine
4.4.4 In-Force Business Configurator
As of Release 5.1, assignments of business transactions to defined products can be performed in In-Force Business
Configurator (IFBC). Specifically, you assign business transactions to policy templates related to main axis entities
such as the Policy, Contract Bundle, Contract, Coverage Bundle, Coverage, and Subcoverage.
As a result, when you select the context menu of one of the main axis elements, all of the business transactions
assigned to that main axis template in IFBC and available in the running business process, and they are displayed.
When you have selected a particular main axis template in IFBC, the business transactions assigned to this template
will be displayed in the tabstrip „Bus.Transactions“. This section consists of three subscreens.
72
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
Example
Figure: Available and assigned business transactions in the Change business process for template 92H0000S0001 (example)
Business Process
A business process in which business transaction assignments are available is displayed on the screen. The following
business processes can be selected:
New Business
Display Application
Change
Universal Change
Inquiry
Resetting - Initial Screen
Resetting - Processing
Reversal
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved. 73
Scroll in Journal
Sample Application
Available Business Transactions
In the “Available BusTransactions” section of the screen, all of the business transactions that fulfill the following
requirements are displayed. They are:
Available in the currently selected Business Process
Available at the execution level of the current template
Available in the line of business of the current template
Not yet assigned to the current template
Note
The above information about a business transaction must have been already defined in Customizing (see
Customizing of Control Parameters of a Business Transaction). For instance, a partner- or customer-owned
business transaction has to be customized in this activity before it can be displayed as available in IFBC.
Assigned Business Transactions
All business transactions available in the selected business process that are already assigned to the current template
are displayed in this section. Note that assigned business transactions can be grouped in a predefined folder structure
as described in Business Transaction Folders.
When assigning or unassigning business transactions, a business user is able to execute the following actions:
Actions Button
Assignment of business transactions (from right to left) using drag and drop or the
button.
Unassignment of business transactions or grouping into business transaction folders
(from left to right) using drag and drop or the button.
Change of business transactions order or grouping into business transaction folders
(up/down) using drag and drop or the buttons.
Note
The order of displayed folders cannot be changed in IFBC. Use the Customizing
activity Assign Business Transaction Folders to Business Processes for this issue.
74
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
4.4.5 Business Transaction Folders
As of FS-PM 5.1, business transaction folders, intended to group business transactions, can be separately defined in
two new Customizing activities called Define Business Transactions Folders and Assign Business Transaction
Folders to Business Processes.
Figure: Customizing activities for defining business transaction folders
Define Business Transaction Folders
You define a new folder by entering a folder ID and a description.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved. 75
Figure: Example for pre-defined folders
Assign Business Transaction Folders to Business Processes
Defined folders can be assigned to several business processes by entering a folder ID, a business process, and a
sequence number that determines in which sequence a folder shall be displayed in the context menu.
Figure: Assignment of sample folders to business processes
In addition, a folder hierarchy can be defined by entering a parent folder in the Main Folder ID field.
When you select a business process in IFBC, the folder structure defined for the selected business process will be
displayed, so that assigned business transactions can be grouped into defined folders.
Note
Folders with no business transactions will not be displayed in the context menu.
76
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
4.5 Service Enablement of Change Process and Business Transactions
As of FS-PM Release 5.3, the implementation of the Change business process has been enhanced to enable the
execution of business transactions in external systems and in an omnichannel environment. For this, a new Change
API is provided. You can use this Change API, for instance, to execute business transactions:
By calling an RFC
By calling an enterprise service
Using ODATA services implemented in the NetWeaver Gateway
The first two scenarios are supported for selected business transactions in FS-PM standard product. Examples will be
provided here which you can further examine in the system.
The API classes for business transactions as described in API Class of Business Transaction are reused as is. There is
no need to adapt or enhance existing API classes here to enable an already implemented business transaction.
Caution
If the new business transaction does not have to be executable in SAP GUI some of the previously mentioned
implementation steps, especially in the area of PBT Customizing, may not be necessary.
4.5.1 The Change API
A new hierarchy of APIs (naming convention /PM0/*SVC*API) is provided to support the service enablement of the
existing business processes.
Figure: Class diagram of new Change API /PM0/CL_ABP_SCV_CHG_PROC_API available as of Release 5.3
The API to be used in the context of service enablement of business transactions is
/PM0/CL_ABP_SVC_CHG_PROC_API. This class can be used to run the Change business process in the background
and provides the functionalities that are common to all business transactions. It can create or resume a Change
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved. 77
Business application, execute a generic business transaction on a loaded Change Business application and save or
release this application.
As of FS-PM Release 5.3, the following restrictions apply to the Change process API implementation:
The API does not support out-of-sequence changes.
The API does not support postdating.
The API releases the application using the update release variant, which has fewer steps than the one for the
dialog. However, the positioning at the end of the business process has been added as a method in the API.
Method: /PM0/IF_ABP_SVC_CHG_PROC_API~START_CHANGE_PROCESS
Related business requirement: Create/resume a change business application in order to execute a change
General purpose/use
of method
Depending on whether the input is an application number or a policy number, the
method loads the business object at runtime, by resuming or creating an
application. In the case of create, the policy is positioned to the effective date
given as input. The business process assigned to the application is A.
Current constraints Not supported: Out-of-sequence changes, postdating.
Method: /PM0/IF_ABP_SVC_CHG_PROC_API~EXECUTE_BTX
Related business requirement: Execute a business transaction in background
General purpose/use
of method
Executes a business transaction on a loaded Change Business application in a
generic way. The business transaction, now also known as change type, is given
as input.
Current constraints
Method: /PM0/IF_ABP_SVC_CHG_PROC_API~GET_DEFAULT_SERVICE_DC
Related business requirement: Execute a business transaction in background and support extensibility of
business transaction
General purpose/use
of method
Creates the data container instance for the business transaction to be executed.
In the case of service-enabled BTXs, the data container will be of type MAPBOX.
Current constraints
Method: /PM0/IF_ABP_SVC_PROC_API~RELEASE_APPLICATION
Related business requirement: Release a Change Business application
General purpose/use
of method
Releases an application for the business processes P (Update) and A (Change).
Current constraints
78
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
Method: /PM0/IF_ABP_SVC_PROC_API~ SAVE_APPLICATION
Related business requirement: Save a Change Business application
General purpose/use
of method
Saves an application.
Current constraints
Method: /PM0/IF_ABP_SVC_PROC_API~ REJECT_APPLICATION
Related business requirement: Reject a Change Business application
General purpose/use
of method
Rejects an application.
Current constraints
Method: /PM0/IF_ABP_SVC_PROC_API~ RESUME_APPLICATION
Related business requirement: Resume a Change Business application
General purpose/use
of method
Resumes an application.
Current constraints
4.5.2 Executing Business Transactions by RFC
It depends on the specific implementation landscape and requirements if a RFC should be built in a customer
implementation project. From a technical perspective, it is also possible to call the new BTX service API directly in an
enterprise service or by NetWeaver Gateway ODATA services. However, for business transactions built by
development partners, an RFC is required.
In the following diagram, you can see the execution flow of a business transaction. The blue objects are common to all
business transactions. The RFC, the BTX service API, the MAP BOX, and the BAdIs are business transaction-specific
and must be created for each service-enabled business transaction.
The steps are similar regardless which BTX is implemented.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved. 79
Figure: Diagram of interaction RFC - BTX service API and change API for a shipped business transaction
For the service enablement of a BTX that is to be build, the following steps are required for development partners:
1. Define the input and output structures based on the business requirements: The input and output must be
easy to understand and well documented. The structures used in the RFC shall be enhanceable.
2. Create the RFC: It must be possible to enhance the input and output, so the ExtensionIN and ExtensionOut
tables must be part of the definition.
3. Create the BAdI for the processing of the input (should be called in the MAPBOX) and the processing of the
output (should be called in the RFC, before release)
4. Create the BTX service API which uses the change service API for managing the application and executing
the business transaction.
5. Create the MapBox and the SET interface for the business driven input structures. The MapBox does the
mapping to FS-PM structures during the execution of the business transaction. Also the Customizing must
be updated (transaction SE43).
For the service enablement of a customer-built business transaction, the change API should be used for the execution
of the change process in the background. The following steps are recommended for customers:
1. Define the input and the output structures based on the business requirements: The input and output must
be easy to understand and well documented.
2. Create the RFC.
3. Create the BTX service API which uses the change service API for managing the application and executing
the business transaction. In the figure above, the necessary calls of the change API are described, the flow
should be the same for all business transactions.
4. If a mapping logic is needed, create the MapBox and customize it in transaction SE43.
80
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
4.5.2.1 BTX Service API
The BTX service API orchestrates the calls of the change API for a specific business transaction. The most important
methods are:
Example
BTX Service API for Change Beneficiary /PM0/CL_ABP_SVC_BTX_BNF_API.
Method: CHECK_PREPARE_INPUT
Related business requirement: Perform consistency checks for the input
General purpose/use
of method
Checks if the minimum input data required for the execution of the BTX is
provided by the caller. Some of the input fields are filled with default values if not
provided
Current constraints
Method: EXECUTE
Related business requirement: Execute business transaction on application as valid of effective date
General purpose/use
of method
Sets the data in the MapBox and calls the change API for the specific BTX.
Current constraints
Method: READ_OUTPUT
Related business requirement: provide a business driven output
General purpose/use
of method
Reads the relevant output from the application after the execution of the BTX.
Current constraints
Method: FINALIZE
Related business requirement: Execute the business transaction in simulation, save, or release mode
General purpose/use
of method
Depending on the input, the corresponding methods of the change API are called
for releasing or saving the application. For simulation mode, or in case of error,
nothing is stored in the database.
Current constraints
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved. 81
4.5.2.2 RFC
The RFC can be called directly or can be used inside an enterprise service or OData service. The specific input and
output structures must be defined from a business point of view and should be enhanceable (character-type or
numeric).
For all RFCs, the parameters EXTENSIONIN, EXTENSIONOUT and MESSAGES must be provided.
The logic inside the RFC must be simple - basically the logic resumes to the call of the BTX Service API and the BAdI
call for enhancing the output.
Example
RFC for execution of business transaction Change Beneficiary: /PM0/ABT_SVC_BNFCRY_AMD. This RFC also
provides you with an example how to implement the simulation of a business transaction.
4.5.2.3 MapBox
Each business transaction RFC should have its own MapBox. The MapBox works like a data container with a new
interface for the set method, allowing the input to be more flexible, based on business use cases. The existing interface
for the get method will be implemented so that it also does the mapping at runtime.
At the beginning of the process, the MapBox is filled with the input received from the RFC (including EXTENSIONIN
parameter). During the execution of the BTX steps, when the get method is called, the MapBox does the mapping to
the technical structures and calls a BAdI method so that the customer can enhance the input and do their own
mapping.
The MapBox class shall be added to developer Customizing (transaction SE43), as a new type of data container
(MAP_BOX).
Example
MapBox for business transaction Change Beneficiary /PM0/CL_MAPBOX_SVC_BNY: /PM0/IF_MAPBOX_SVC_BNY
82
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
4.5.2.4 Enhancement of RFCs Provided by FS-PM Standard Product or Development Partners
The specific input and output structures must be defined from a business point of view and shall be enhanceable
(character-type or numeric). By appending the structure with partner and customer fields, the input is automatically
moved to the RFC.
If enhancements of the input/output are needed that imply more than field enhancement the EXTENSIONIN and
EXTENSIONOUT parameters can be used.
For the processing of the EXTENSIONIN parameter, the BAdI method EXECUTE_MAPPING called by the MAPBOX
shall be used.
For the processing of the EXTENSIONOUT parameter, the BAdI method PROCESS_EXTENSIONOUT, called by the
RFC, shall be used. Customers/partners can do their own mapping by implementing the BAdI method
EXECUTE_MAPPING.
Example
BAdI for business transaction Change Beneficiary: /PM0/ABT_SVC_BNFCRY_BADI.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved. 83
The following diagram gives an overview of the execution of the enhancement options:
Figure: Execution of enhancement options in RFC call
84
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
Depending on the type of RFC (operation mode create, update, read, find or retrieve), different enhancement patterns
are suitable.
For RFCs that perform a read, we do not need to have the ExtensionIN input parameter or the Process ExtensionIN
BAdI call since the input is minimal and usually resumes to a technical key.
The Process ExtensionOut BAdI call is done at the end of the RFC, so that the customer can enhance the output with
their own entities.
Figure: Execution of enhancement options in a READ RFC call
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved. 85
For Create, Update, Find and Retrieve RFCs, the input shall be enhanced with the ExtensionIN parameter.
For Create or Update, a development partner might want to add own entities to the input. For Find, client-specific
search objects might be needed. For Retrieve, the client might want to specify nodes that must be included in the
response.
The enhancement is done in a similar way for the four operations. Depending on the Service API, a suitable place must
be chosen for the call of the Process ExtensionIN BAdI call, after the mapping to internal input structures. The Process
ExtensionOUT BAdI call happens at the end of the RFC:
Figure: Execution of enhancement options in an RFC call
86
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
The BAdIs mentioned above are available in the Implementation Guide on SAP Service Marketplace at
http://service.sap.com/instguides under Policy Management -> Integration -> Services -> Remote Function Calls
(RFCs).
For more information about the extensibility of FS-PM, see the SAP Policy Management 5.3: Enhancement Guide
available on SAP Service Marketplace.
4.5.3 Example: Execution of Business Transaction through Enterprise Services
This section describes where in the system you can find information about the implementation of an enterprise service
for execution of a business transaction, based on the Change Beneficiary example. It is assumed here that you have
knowledge of designing and implementing enterprise services. For an overview of the topic, see SAP Help Portal at
http://help.sap.com/saphelp_nwce72/helpdata/en/61/fec608bc27654daadb20c1e6da7dd1/content.htm?frameset
=/en/9c/5f119cd4704c8d967f0d6d155a2d2c/frameset.htm¤t_toc=/en/ca/97f68ba5034d0fb21c518f0cac14
32/plain.htm&node_id=7&show_children=false.
You can reach the enterprise service repository with transaction SPROXY. The standard setting, i.e. ESR Browser, to
easily access the enterprise services menu can be set on the SAP Easy Access screen under Utilities-> Settings, Proxy
Generation tab, Enterprise Service Browser setting.
Figure: Setting the ESR Browser
Choose a service interface from the tree structure on the left in order to see its details and further information. For
example, service operation Change Beneficiary can be found in the service interface
InsurancePolicyProcessingManagePolicyIn. The corresponding implementing class name, /PM0/CL_PLCYPPLCY_M,
is displayed on the Properties tab.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved. 87
Figure: Service information for policy processing interface
The service is run by clicking the Test icon at the top (F8 key). In the next dialog box, you choose the relevant method
name, i.e. UpdateInsurancePolicyBenefitsRight.
Figure: Selection of the Change Beneficiary service operation
Once the method name is chosen, the following screen displays the request message for the service. The values of the
attributes in the XML file have to be provided within the XML editor. When everything is set, the service is ready for
execution.
The enterprise services for policies are documented in release note /PM0/FSPM_530_POLSV. Transaction SE61
provides access to the release note. Choose Release Notes in the field Document Class and then search for the
specified release note.
A detailed description of all delivered services is available in SAP Note 2000805.
88
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
BAdIs are available for enhancing the service functionality. In the context of business transactions, corresponding
activities can be found in Customizing for Policy Management under Integration -> Services -> Enterprise Services.
4.6 Overview of Major BAdIs Relevant in the Context of Business Transactions
Here is a short overview of the most important BAdIs relevant in the context of business transactions of the Change
business process:
Enhancement Spot BAdI Definition Purpose/Use
/PM0/ABP_BTX_ES /PM0/ABP_BTX_BADI_MFIM For partners and customers to
implement their own checks for
shipped BTXs regarding
availability and executability of
the business transaction. See API
Class of Business Transaction
and Business Components and
Business Functions
/PM0/ABP_PROC_DERIVE_ES /PM0/ABP_PROC_DERIVE_BADI Implementations of this BAdI
execute the shipped checks &
derivations at process points of
time INIT, EXEC and END for
shipped BAdIs. Not for
implementation by customers.
See API Class of Business
Transaction and Business
Components and Business
Functions
/PM0/ABP_PROC_DERIV_CUST_ES /PM0/ABP_PROC_DERIVE_CUST_
BADI
For partners and customers to
implement their own checks &
derivations at points of time INIT,
EXEC and END for shipped
business transactions. See API
Class of Business Transaction
and Business Components and
Business Functions
/PM0/ABP_AMD_CHECK_ES e.g.
/PM0/ABP_TVR_CHECK_BADI
This enhancement spot contains
a BAdI for each shipped business
transaction for implementing the
check for changes. BAdI can be
overimplemented by partners or
customers. See API Class of
Business Transaction and
Business Components and
Business Functions
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved. 89
Enhancement Spot BAdI Definition Purpose/Use
/PM0/ABP_AMD_CHECK_ES /PM0/ABP_BTXPREDCHK_BADI Implementation of this BAdI
determines the behavior of a
business transaction when it tries
to trigger postdating. Can be
implemented by partners and
customers. See Customizing of
Control Parameters of a Business
Transaction.
/PM0/ABP_BCRDO_ES /PM0/ABP_REIMPL_RULE_BADI Implementation of this BAdI
determines the behavior of a
business transaction in
reimplementation mode. See
Customizing of Business
Transactions
/PM0/ABP_DC_ES /PM0/ABP_DC_CHECK_BADI
/PM0/ABP_DC_COMPARE_BADI
/PM0/ABP_DC_MERGE_BADI
/PM0/ABP_DC_INIT_BADI
In case of smaller extensions to
shipped business transactions,
you can do the required
enhancements of data containers
by implementing these BAdIs. See
Data Container and Filler Classes
for an overview on this issue.
/PM0/ABP_BCRDO_ES /PM0/ABP_TRANSFER_CSTM_BA
DI
In case of smaller extensions to
shipped business transactions,
you can do the required
enhancements of filler classes by
implementing this BAdI. See Data
Container and Filler Classes for an
overview on this issue.
/PM0/ABT_SVC_CHANGE_BADI_ES /PM0/IF_ABT_SVC_*_BADI This is a business transaction
specific BAdI that can be used to
change the mapping or to
enhance the input/output data of
a RFC enabled BTX. See
Executing Business Transactions
by RFC for an overview on this
issue.
90
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
4.7 Enhancement of Standard Business Transactions
Business transactions can be enhanced in the following ways:
Scenario A: Partner/customer adds standard fields or their own fields (Append/Include)
Scenario B: Partner creates their own entities, their own API/subprocesses
Scenario C: Partner creates their own entities, no own API with their own subprocesses for main axis business
transactions
Scenario D: Partner adds their own field to standard entities, their own API, no own sub-process
4.7.1 Scenario A
When a partner or customer has added new fields to one of our standard SAP entities that is already processed in a
business transaction, the following enhancements have to be done:
Creation of a new view with the partner/customer specific fields. This new view has to be placed into the dialog
model of the subcontroller model belonging to the business transaction. For further information, consult the
enhancement guide.
Maintenance of the Customizing of Control Parameters of a business transaction. For further information, see the
relevant section in this document.
[Optional] Add the required Check and Derive rules to validate the user input of these new fields. For further
information, see the FS-PM Enhancement Guide.
4.7.2 Scenario B
In this case, the partner has to implement their own business transaction.
4.7.3 Scenario C
Partners are allowed to enhance the core Policy business object. Therefore an enhancement possibility was introduced
to extent the standard main axis business transactions (such as ‘Create and Process Contract’) to call partner's own
subprocesses for maintaining the input fields of the new entity.
Within the partner subprocesses, it is not allowed to do the following:
Calculate
Call commits
Load business objects
Start time model functions
Use the same names for commands that are already used (names for commands must be unique)
Use cross-application commands with the indicator Subprocess = False
Call external systems
For the integration of partner subprocesses into some dedicated business transactions (such as main axis business
transactions), FS-PM provides the following infrastructure:
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved. 91
Partner/Customer
init data input calculatework finish
init data input work finish
sub_start sub_back
Figure: Typical flowchart for a business transaction that can be enhanced by a partner
Here it is assumed that business transactions will run in dialog mode as well as in background mode.
Sub_start is triggered with command CMD_M_SUB_ENTER, and sub_back is triggered with CMD_M_SUB_BACK.
In order to find out which business transactions provide the infrastructure described above, start the class builder
(transaction SE80) and search for the implementation classes of interface /PM0/IF_ABP_BTX_DLG_EXT.
Figure: How to find out for which business transactions FS-PM provides an enhancement concept for partners
If you require an additional business transaction with the special infrastructure, contact SAP.
The following activities have to be done by partners using option C:
Create your own dialog (screen, and so on)
92
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
Create process model (subprocess)
Implement BAdIs
Maintain the developer Customizing activities Configure Control Parameters for Subprocesses and Configure
Control Parameters for Business Transactions
Create your own data container (including Customizing entries)
Create your own dialog
First, you have to create your own dialog. For further information, see the FS-PM Enhancement Guide. The
pushbuttons are available by using commands.
Create subprocess
To create your own subprocess, you have to create a class. An example of how such a class should look is class
/PM0/CL_ABP_BTX_CDR.
Figure: Sample class for Change Creditor subprocess
In addition to this, you must also create a PBT model. An example of how such a model should look is the process
model P_B_S_CDR_DETAIL (Change Creditor).
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved. 93
Figure: Sample process model for Change Creditor
Note
This example has more than one exit, but currently only one exit is supported for subprocesses.
Implement BAdIs (of enhancement spot /PM0/ABP_BTX_ES)
The following BAdIs have to be implemented:
/PM0/ABP_BTX_EXT_BADI (BAdI for BTrans for enhancement of partner actions)
Interface /PM0/IF_ABP_BTX_EXT_BADI
o Method REGISTER (register of commands)
o Method UNREGISTER (unregister of commands)
o Method SETUP (setup of subprocess)
/PM0/ABP_BTX_PROC_ADD_LOB_BADI (BAdI to process enhancement LoBs)
This BAdI has to be implemented when you create your own sibling entities (for instance, in a partner
enhancement)
Interface /PM0/IF_ABP_BTX_PROC_ADD_LOB
o Method PROCESS_ADDITIONAL_LOB (processing of enhancement LoB)
/PM0/ABP_BTX_PROC_ADD_SUB_BADI (BAdI to process non-standard entities, see Create Own Data
Container)
Interface /PM0/IF_ABP_BTX_PROC_ADD_SUB
o Method PROCESS_ADDITIONAL_ENTITY (processing of entities unknown in standard system)
For more information, see the Online Help in the Enhancement Spot Editor.
94
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved.
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
Create Own Data Container
Processes that have been enhanced by subprocesses must also be able to handle the input data of the subprocess.
You can only create your own data container for those business transactions where SAP included the BAdI
/PM0/ABP_BTX_PROC_ADD_SUB_BADI.
The next section describes how partners can create their own data container for the following subprocesses.
+init()
+work()
+calculate()
+finish()
+process_data()
SampleBTX
+get_SAP_entity()
+set_SAP_entity()
<<interface>>
IF_SampleBTX
Figure: Sample data container with interface
SampleBTX defines its data container interface. Thus it will be able to process its input data. A subprocess requires its
own API and data container interface.
+init()
+work()
+finish()
+process_data()
Partner/Customer
Subprocess
+get_Partner/Customer_entity()
+set_Partner/Customer_entity()
<<interface>>
IF_Partner/Customer
Subprocess
Figure: Sample partner data container with interface
For example, an additional data container is be implemented for group insurance. FS-PM provides an implementation
of a data container with a persistence layer and all functionality for group insurance. So the first step is to provide a
new data container implementation.
+get_SAP_entity()
+set_SAP_entity()
<<interface>>
IF_SampleBTX
+get_Partner/Customer_entity()
+set_Partner/Customer_entity()
<<interface>>
IF_Partner/Customer
Subprocess
+init()
+work()
+calculate()
+finish()
+process_data()
GroupDC_Sample_BTX_Impl
Figure: Sample data container for group insurance + partner interface
SAP Policy Management 5.3
Implementing a Business Transaction: Steps in Detail
CUSTOMER
© 2015 SAP AG or an SAP affiliate company. All rights reserved. 95
We recommend that delegation is used in order to avoid coding for the standard data container implementation. Thus,
all methods from standard business transaction will be delegated. You only need your own implementation for the
additional data that is required by the subprocess.
+get_SAP_entity()
+set_SAP_entity()
<<interface>>
IF_SampleBTX
+get_Partner/Customer_entity()
+set_Partner/Customer_entity()
<<interface>>
IF_Partner/Customer
Subprocess
+init()
+work()
+calculate()
+finish()
+process_data()
GroupDC_Sample_BTX_Impl
+init()
+work()
+finish()
+process_data()
Partner/CustomerDC_Impl
Figure: Sample interaction between partner data container and standard data container
The new PartnerDC_Impl is now able to store all the required input data.
In addition to this, the BAdI /PM0/ABP_BTX_PROC_ADD_SUB_BADI has to be implemented. For demo code, view the
business transactions that are already shipped (for example, method process_sub_entities of class
/PM0/IF_ABP_BTX_DLG_EXT).
Finally, the necessary Customizing has to be carried out (view cluster /PM0/ABU_CCDC).
4.7.4 Scenario D
In this case, the partner has to implement their own business transaction.
www.sap.com/contactsap
© 2015 SAP AG or an SAP affiliate company. All rights reserved.
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.
National product specifications may vary.
These materials are provided by SAP AG and its affiliated
companies (“SAP Group”) for informational purposes only, without
representation or warranty of any kind, and SAP Group shall not be
liable for errors or omissions with respect to the materials. The only
warranties for SAP Group products and services are those that are
set forth in the express warranty statements accompanying such
products and services, if any. Nothing herein should be construed as
constituting an additional warranty.
SAP and other SAP products and services mentioned herein as well
as their respective logos are trademarks or registered trademarks of
SAP AG in Germany and other countries. Please see
www.sap.com/corporate-en/legal/copyright/index.epx#trademark
for additional trademark information and notices.
3993
Top Related