SAP Policy Management 5.3

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 .


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.


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


Introduction

CUSTOMER


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



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

http://help.sap.com/

http://help.sap.com/insurance-pm


General Comments on How to Implement a Business Transaction

CUSTOMER


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



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.


Implementing a Business Transaction: Overview of Major Steps

CUSTOMER


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



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.


Implementing a Business Transaction: Steps in Detail

CUSTOMER


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




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.


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


The superclass implementation executes the general steps before the call of the

product engine and before the call itself. The following steps are performed:



CUSTOMER


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.


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


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.


implementation


Method: /PM0/IF_ABP_BTX_PROCESS~GET_PREDATE_TRIGGER

Related business requirement: Postdating of a business transaction

General purpose/use


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




Method: /PM0/IF_ABP_BTX_PROCESS~GET_PREDATE_TRIGGER


implementation


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


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.


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


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.


implementation


Method: /PM0/IF_ABP_BTX_PROCESS~HANDLE_FAILED_BTX_CONTEXT

Technical

General purpose/use


Handling/cleanup in case business transaction caused errors for one or more

execution levels.



implementation


Method: /PM0/IF_ABP_BTX_PROCESS~INIT

Related business requirement: Business-related checks and derivations that shall be executed when

starting the business transaction



CUSTOMER


Method: /PM0/IF_ABP_BTX_PROCESS~INIT

General purpose/use


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



implementation


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


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.



implementation


16

CUSTOMER




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


Cleanup work when leaving the business transaction.

The BTX-specific cleanup takes place in the reimplementation of the method

tech_cleanup_btxdependent().



implementation

This method just inherits from the superclass.

Method: /PM0/IF_ABP_BTX_TECH~GET_METAINFO

Technical

General purpose/use


Sets values of the control parameters. These are determined from internal and

IMG Customizing, which is described in later sections.



implementation


Method: /PM0/IF_ABP_BTX_TECH~SETUP

Technical

General purpose/use


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().


implementation


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


Cleanup work when reversing the business transaction in dialog mode.




CUSTOMER


Method: DLG_CANCEL_EXIT_FROM_DIALOG

This method is called in dialog processing only.


implementation


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


Determines if any data has changed.

The BTX-dependent reimplementation of the method

check_for_change_btxdependent() is required in this case.



implementation


DLG_CLEANUP

Technical

General purpose/use


Cleans up the data that was needed for the dialog, such as the navigation tree

state, property list, session stack.




implementation


DLG_CLEAR_LOGGER

Technical

General purpose/use


Deletes old error messages from the logger.




implementation


DLG_CNL_TRANS

Technical

General purpose/use


Cancels the open subtransaction and clears the member attribute

MF_DIRECT_APPROVE that triggers direct approval in a business transaction.



Change Tariff Variant This method just inherits from the superclass.

18

CUSTOMER




DLG_CNL_TRANS

implementation

DLG_CTA_TRANS

Technical

General purpose/use


Closes the open sub transaction.




implementation


DLG_DEL_COMDIFF

Related business requirement: Business transaction allows maintenance of alternative commission

participants

General purpose/use


Handling of alternative commission participants in dialog mode.

This method does not need not to be reimplemented.



implementation


DLG_EXIT_FROM_COMDIFF


participants

General purpose/use


The superclass implementation of the process method cleans up the data used

in the alternative commission participant subproces .




implementation


P_B_P_APPROVE

Technical

General purpose/use


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).





CUSTOMER


P_B_P_APPROVE


implementation


DLG_EXIT_FROM_DIALOG

Technical

General purpose/use


Cleans up the data when leaving the business transaction in dialog mode.




implementation


DLG_PREPARE_COMDIFF_ADD


participants

General purpose/use


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().




implementation


DLG_PREPARE_COMDIFF_MOD


participants

General purpose/use


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



implementation


DLG_PREPARE_FOR_DIALOG

Technical

General purpose/use


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




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.



implementation


DLG_PREPARE_FOR_DIALOG_BTX

technical

General purpose/use


If needed, this method can be reimplemented by partner or customer owned




implementation


DLG_REDO_LOAD

Related business requirement: Reimplementation of business transaction

General purpose/use


Loads the redo data (the data maintained in the original execution of the BTX)

in the application in dialog mode.


Only the BTX-specific method dlg_redo_load_btxdependent() can be

reimplemented.



implementation


DLG_SHIFT_LOAD

Related business requirement: Shift of effective date of a BTX; Revise business transaction data

General purpose/use


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.




implementation


DLG_REDO_LOAD_BTXDEPENDENT

Related business requirements: Reimplementation



CUSTOMER


DLG_REDO_LOAD_BTXDEPENDENT

General purpose/use


If needed, this method can be reimplemented by partner- or customer-owned




implementation


DLG_SHIFT_LOAD_BTXDEPENDENT

Related business requirements: Shift of effective date of business transaction and revision of business

transaction data

General purpose/use


If needed, this method can be reimplemented by partner- or customer-owned




implementation


DLG_SWITCH_REDO_SHIFT

Related business requirements: Reimplementation, shift of effective date of business transaction and

revision of business transaction data

General purpose/use


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.




implementation


DLG_REDO_RESET

Related business requirements: Reimplementation, shift of effective date of business transaction and

revision business transaction data

General purpose/use


Resets in dialog mode the data to the state before execution of the business

transaction.




implementation


DLG_REFRESH_LOGGER

Technical

22

CUSTOMER




DLG_REFRESH_LOGGER

General purpose/use


Deletes old messages from the logger.




implementation


DLG_RESET_ERROR_BEFORE_DIALOG

Technical

General purpose/use


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.




Implementation


CALL_TAX_SETUP

Related business requirement: Handling of tax relevance of a BTX.

General purpose/use


Calls set up for the taxation subprocess. All shipped business transactions are

prepared for handling taxes.



implementation


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


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.


implementation


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


Must be reimplemented by any BTX.



CUSTOMER


CHECK_FOR_CHANGE_BTXDEPENDENT


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


Check to ensure that such methods are redefined when called.

This method can be redefined by BTX.


implementation


CHK_EXEC_ALLOWED_ON_LEVEL_BTXD

Related business requirement: Executability of a business transaction at certain levels

General purpose/use


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.


implementation


CREATE_NEW_STATE_DC_BTXDPNDNT

Related business requirement: New state of application is needed for processing during completion of

business transaction

General purpose/use


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.


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


General purpose/use Stores BTX-specific data at start of BTX in a data container which is passed to

24

CUSTOMER




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.


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


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().



implementation


GET_BTXPROCCTRL_BTXDEPENDENT

Business-related requirement: Sets the BTX-specific values for some parameters that determine the

behavior of the BTX.

General purpose/use


If required, this method can be reimplemented by partner- or customer-owned



implementation

This method is reimplemented by the BTX to set values for additional

parameters.

GET_REDO_CMD_INIT_BTXDEPENDENT

Technical

General purpose/use




Special issue for a shipped business transaction. Should not be required for

customer- or partner-owned BTX.


implementation


IS_AVAILABLE_BTXDEPENDENT

Related business requirement: Availability of a business transaction.

General purpose/use BTX-dependent checks for the availability of the BTX.



CUSTOMER


IS_AVAILABLE_BTXDEPENDENT

of superclass method If required, this method can be reimplemented by partner- or customer-owned



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


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.


implementation


IS_EXECUTABLE_MNDTRY_BTX



General purpose/use


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.


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



General purpose/use


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.


implementation



Related business requirement: Are there conditions where the business transaction shall not be

executable although it is available?

26

CUSTOMER





General purpose/use


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.


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


Checks from the completion service Customizing if the fund-btx-id differs from

NFBTX_ID. If so, funds relevance of the BTX is assumed.



implementation


PRE_FINISH_BTXDEPENDENT

Related business requirement: Business-related processing steps before completing the business

transaction

General purpose/use





implementation


FINISH_BTXDEPENDENT

Related business requirement: Finalize business transaction if it can be completed, e.g. provide

components.

General purpose/use





implementation


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



CUSTOMER


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


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.


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


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.


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




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


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.



implementation


PROCESS_ENTER_COMDIFF_DATA

Related business requirement: Alternative commission participants can be maintained for a business

transaction.

General purpose/use


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.



implementation


PROCESS_ENTER_TAX_DATA

Related business requirement: Taxation handling is needed for a business transaction.

General purpose/use


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.



CUSTOMER


PROCESS_ENTER_TAX_DATA



implementation


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


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()



implementation


PROVIDE_INTERFACES

Related business requirement: The interfaces to other installed applications must be supplied with data

General purpose/use


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()



implementation


TAKE_SNAPSHOT

Related business requirement: Keep parts of the application objects for further usage

General purpose/use


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




TAKE_SNAPSHOT


implementation


TECH_CLEANUP_BTXDEPENDENT

technical

General purpose/use


The BTX-specific cleanup work takes place in this method.

This method can be reimplemented.


implementation

Empty implementation, nothing to be done here for this BTX.

TECH_SETUP_BTXDEPENDENT

technical

General purpose/use


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.


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


Clean up the clone if there is one.


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.


implementation


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.



CUSTOMER


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


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


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.


(/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


The implementation of the method initializes the business transaction.

The methods:

32

CUSTOMER




Method: /PM0/IF_ABP_BPU_BTX_BTS~INIT_BTX

/pm0/if_abp_btx_process~init() (of BTX API)

init_btxdependent() are executed here.


(/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


The implementation of the method initializes the BTX container.

The BTX API method

process_determine_btx_data() is executed here.


(/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


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()


of BTX API are executed here.


(/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


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()



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



CUSTOMER


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


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


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


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.


(/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




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.



CUSTOMER


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




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



CUSTOMER


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




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



CUSTOMER


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




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):



CUSTOMER


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




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.



CUSTOMER


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




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



CUSTOMER


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




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.



CUSTOMER


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




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



CUSTOMER


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




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:



CUSTOMER


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




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.



CUSTOMER


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




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.



CUSTOMER


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




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



CUSTOMER


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




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.



CUSTOMER


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




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).



CUSTOMER


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




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.



CUSTOMER


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




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.



CUSTOMER


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




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



CUSTOMER


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




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



CUSTOMER


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




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.



CUSTOMER


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




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



CUSTOMER


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




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.



CUSTOMER


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




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



CUSTOMER


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


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




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.



CUSTOMER


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




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



CUSTOMER


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




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.



CUSTOMER


The following diagram gives an overview of the execution of the enhancement options:

Figure: Execution of enhancement options in RFC call

84

CUSTOMER




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



CUSTOMER


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




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&current_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.

http://service.sap.com/instguides

http://help.sap.com/saphelp_nwce72/helpdata/en/61/fec608bc27654daadb20c1e6da7dd1/content.htm?frameset=/en/9c/5f119cd4704c8d967f0d6d155a2d2c/frameset.htm&current_toc=/en/ca/97f68ba5034d0fb21c518f0cac1432/plain.htm&node_id=7&show_children=false





CUSTOMER


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




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



CUSTOMER


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




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:



CUSTOMER


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




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).



CUSTOMER


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




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



<<interface>>

IF_Partner/Customer

Subprocess

+init()

+work()

+calculate()

+finish()

+process_data()

GroupDC_Sample_BTX_Impl

Figure: Sample data container for group insurance + partner interface



CUSTOMER


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



<<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


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

http://www.sap.com/contactsap

http://www.sap.com/corporate-en/legal/copyright/index.epx#trademark

SAP Policy Management 5.3

Documents

Transcript of SAP Policy Management 5.3