SAP Policy Management 5.3 SP03

Transcription

1 How-To Guide SAP Policy Management Document Version: Guide for Implementing Business Transactions

2 Typographic Conventions Type Style Example Description 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 EXAMPLE Example Example <Example> Emphasized words or expressions. 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. 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. Exact user entry. These are words or characters that you enter in the system exactly as they appear in the documentation. Variable user entry. Angle brackets indicate that you replace these words and characters with appropriate entries to make entries in the system. EXAM PLE Keys on the keyboard, for example, F2 or EN TER SAP AG or an SAP affiliate company. All rights reserved. Typographic Conventions

3 Document History Version Date Change First official version of this guide The following sections were updated due to enhancements or changes available with 5.3 SP01: API Class of Business Transaction Executing Business Transactions by RFC BTX Service API BTX RFC MapBox The following sections were updated due to enhancements or changes available with 5.3 SP02: Defining Journal Entries Service Enabling of Change Process The Change API The Read API The following sections were updated due to enhancements or changes available with 5.3 SP03: The Change API Document History 2016 SAP AG or an SAP affiliate company. All rights reserved. 3

4 Table of Contents 1 Introduction Disclaimer About this Document Terminology Important Notes Related Information and Further Useful Links General Comments on How to Implement a Business Transaction Implementing a Business Transaction: Overview of Major Steps Repository Objects API Class of Business Transaction API Class for Executing a Business Transaction in the Background Business Components and Business Functions Data Container and Filler Classes PBT Models Process Model for Business Transaction Subcontroller Model Internal Customizing Customizing of Control Parameters of a Business Transaction Customizing of Control Parameters of Subprocesses Customizing of Completion Service IMG Customizing Customizing of Business Transactions Defining Journal Entries BTS Customizing In-Force Business Configurator Business Transaction Folders Service Enablement of Change Process and Business Transactions The Change API The Read API Executing Business Transactions by RFC Example: Execution of Business Transaction through Enterprise Services Overview of Major BAdIs Relevant in the Context of Business Transactions Enhancement of Standard Business Transactions Scenario A Scenario B Scenario C Scenario D SAP AG or an SAP affiliate company. All rights reserved. Table of Contents

5 1 Introduction 1.1 Disclaimer This guide is not part of SAP product documentation. By using this guide, you agree that (unless expressly stated otherwise in your agreements with SAP) you may not infer any product claims against SAP based on this information. 1.2 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 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 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.3 Terminology The following FS-PM-specific abbreviations are used in this guide: Abbreviation BTX BTrans Term Business Transaction Business Transaction Introduction 2016 SAP AG or an SAP affiliate company. All rights reserved. 5

6 Abbreviation BTS IM PBT IFBC BP LoB FM IPCR Term Business Transaction Scheduler Insurance Mathematics Policy-Based Technology (FS-PM development framework) In-Force Business Configurator Business Process Line of Business Field modifiers Insurance Policy Change Request 1.4 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.5 Related Information and Further Useful Links For more information that is not covered in this guide, see below: SAP Help Portal ( 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 ( SAP Policy Management: Enhancement Guide Further information provided in the SAP for Insurance - Solution Manager Content Online documentation SAP AG or an SAP affiliate company. All rights reserved. Introduction

7 SAP Notes Introduction 2016 SAP AG or an SAP affiliate company. All rights reserved. 7

8 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 re 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 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 SAP AG or an SAP affiliate company. All rights reserved. General Comments on How to Implement a Business Transaction

9 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 (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. General Comments on How to Implement a Business Transaction 2016 SAP AG or an SAP affiliate company. All rights reserved. 9

10 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, re (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 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 SAP AG or an SAP affiliate company. All rights reserved. Implementing a Business Transaction: Overview of Major Steps

11 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: Overview of Major Steps 2016 SAP AG or an SAP affiliate company. All rights reserved. 11

12 4 Implementing a Business Transaction: Steps in Detail This section uses the example of the 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 (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 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 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, 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 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? SAP AG or an SAP affiliate company. All rights reserved.

13 Method: /PM0/IF_ABP_BTX_CHK_ACCESS~IS_AVAILABLE The superclass executes the generally valid checks: 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. 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? The superclass 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. 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. 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 SAP AG or an SAP affiliate company. All rights reserved. 13

14 Method: /PM0/IF_ABP_BTX_PROCESS~CALCULATE The superclass executes the general steps before the call of the product engine and before the call itself. The following steps are performed: 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 re 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. 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 The superclass 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. As mentioned above, the method just inherits from superclass. Method: /PM0/IF_ABP_BTX_PROCESS~GET_PREDATE_TRIGGER Related business requirement: Postdating of a business transaction If the business transaction is postdated, this method determines the origin for postdating and, if supplied, the release date SAP AG or an SAP affiliate company. All rights reserved.

15 Method: /PM0/IF_ABP_BTX_PROCESS~GET_PREDATE_TRIGGER This method is commonly called by the BTS API class. This method does not need to be reimplemented. As mentioned above, the method just inherits from superclass. Method: /PM0/IF_ABP_BTX_PROCESS~HANDLE_CALC_ERRORS Related business requirement: Does the business transaction require the call of the product machine? The superclass 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. 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? The superclass 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. As mentioned above, the method just inherits from the superclass. Method: /PM0/IF_ABP_BTX_PROCESS~HANDLE_FAILED_BTX_CONTEXT Technical Handling/cleanup in case business transaction caused errors for one or more execution levels. This method does not need to be reimplemented. As mentioned above, the method just inherits from the superclass SAP AG or an SAP affiliate company. All rights reserved. 15

16 Method: /PM0/IF_ABP_BTX_PROCESS~INIT Related business requirement: Business-related checks and derivations that shall be executed when starting the business transaction The superclass executes the required steps to initialize the BTX. These include: Setting old-state data container. To do this, the BTX-specific re of the method create_old_state_dc_btxdpndnt() is required. Open transaction Set BO state to in process Execution of business functions for point of time INIT. You can add your own checks by to shipped business transactions and your own business transactions by implementing BAdI /pm0/abp_proc_derive_cust_badi. Handling of charges Check for postdating and change of journal state Handling of taxes This method does not need to be reimplemented. As mentioned above, the method just inherits from the superclass. Method: /PM0/IF_ABP_BTX_PROCESS~PRE_FINISH Related business requirement: Business-related checks and derivations that shall be executed when completing the business transaction The superclass includes process steps to prepare the completion of the business transaction. These includes: Setting new-state data container. To do this, the BTX-specific re of the method create_new_state_dc_btxdpndn() is required. If the BTX does not call the insurance mathematics, the business functions at the END point of time are executed through /pm0/cl_abp_check_and_derive=>check_and_derive_prcend. You can add your own checks to shipped business transactions and your own business transactions by implementing BAdI /pm0/abp_proc_derive_cust_badi BTX-specific executions are performed in the method pre_finish_btxdependent(), which must be reimplemented for customer-owned business transactions. Check for changes. Handling of taxes. This method does not need to be reimplemented. As mentioned above, the method just inherits from the superclass SAP AG or an SAP affiliate company. All rights reserved.

17 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 Cleanup work when leaving the business transaction. The BTX-specific cleanup takes place in the re of the method tech_cleanup_btxdependent(). This method does not need to be reimplemented. This method just inherits from the superclass. Method: /PM0/IF_ABP_BTX_TECH~GET_METAINFO Technical Sets values of the control parameters. These are determined from internal and IMG Customizing, which is described in later sections. This method does not need to be reimplemented. This method just inherits from the superclass. Method: /PM0/IF_ABP_BTX_TECH~SETUP Technical The superclass 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(). This method just inherits from the superclass. Caution Subtransactions in a business transaction are always to be handled with the BTX transaction handler. Here is a reference to it: /pm0/cl_abp_btx_trans_handler=>create_btx_trans_handler() Method: DLG_CANCEL_EXIT_FROM_DIALOG Technical Cleanup work when reversing the business transaction in dialog mode. This method does not need to be reimplemented SAP AG or an SAP affiliate company. All rights reserved. 17

18 Method: DLG_CANCEL_EXIT_FROM_DIALOG This method is called in dialog processing only. This method just inherits from the superclass. DLG_CHECK_FOR_CHANGE Related business requirement: The completion of the business transaction only makes sense if some business-relevant data has changed. Determines if any data has changed. The BTX-dependent re of the method check_for_change_btxdependent() is required in this case. This method is called in dialog processing only. This method just inherits from the superclass. DLG_CLEANUP Technical Cleans up the data that was needed for the dialog, such as the navigation tree state, property list, session stack. This method does not need to be reimplemented. This method is called in dialog processing only. This method just inherits from the superclass. DLG_CLEAR_LOGGER Technical Deletes old error messages from the logger. This method does not need to be reimplemented. This method is called in dialog processing only. This method just inherits from the superclass. DLG_CNL_TRANS Technical Cancels the open subtransaction and clears the member attribute MF_DIRECT_APPROVE that triggers direct approval in a business transaction. This method does not need to be reimplemented. This method is called in dialog processing only SAP AG or an SAP affiliate company. All rights reserved.

19 DLG_CNL_TRANS This method just inherits from the superclass. DLG_CTA_TRANS Technical Closes the open sub transaction. This method does not need to be reimplemented. This method is called in dialog processing only. This method just inherits from the superclass. DLG_DEL_COMDIFF Related business requirement: Business transaction allows maintenance of alternative commission participants Handling of alternative commission participants in dialog mode. This method does not need not to be reimplemented. This method is called in dialog processing only. This method just inherits from the superclass. DLG_EXIT_FROM_COMDIFF Related business requirement: Business transaction allows maintenance of alternative commission participants The superclass of the process method cleans up the data used in the alternative commission participant subproces. This method does not need to be reimplemented. This method is called in dialog processing only. This method just inherits from the superclass. P_B_P_APPROVE Technical The superclass of the process method sets the member attribute MF_DIRECT_APPROVE. This member attribute triggers the direct approval after the business process is completed. Therefore it is handled in the last process node implemenation DLG_EXIT_FROM_DIALOG. This method is called when the business transaction dialog is exited with the command CMD_F_XCT_APPR ( Complete and Release button). This method does not need to be reimplemented SAP AG or an SAP affiliate company. All rights reserved. 19

20 P_B_P_APPROVE This method is called in dialog processing only. This method just inherits from the superclass. DLG_EXIT_FROM_DIALOG Technical Cleans up the data when leaving the business transaction in dialog mode. This method does not need to be reimplemented. This method is called in dialog processing only. This method just inherits from the superclass. DLG_PREPARE_COMDIFF_ADD Related business requirement: Business transaction allows maintenance of alternative commission participants The superclass of the process method prepares data required for the subprocess Add Alternative Commission Participant by calling the method mr_btx_api_sub_comdiff->setup(). This method does not need to be reimplemented. This method is called in dialog processing only. This method just inherits from the superclass. DLG_PREPARE_COMDIFF_MOD Related business requirement: Business transaction allows maintenance of alternative commission participants The superclass of the process method prepares data required for the subprocess Change Alternative Commission Participant by calling the method mr_btx_api_sub_comdiff->setup(). This method does not need to be reimplemented This method is called in dialog processing only. This method just inherits from the superclass. DLG_PREPARE_FOR_DIALOG Technical The superclass sets up the data required for dialog processing by executing following steps: Set navigation tree status disabled SAP AG or an SAP affiliate company. All rights reserved.

21 DLG_PREPARE_FOR_DIALOG Put BTX parameter and BTX ID on the session stack Call the BTX-specific method dlg_prepare_for_dialog_btx(). This method does not need to be reimplemented. Only the BTX-specific method dlg_prepare_for_dialog_btx() should be reimplemented. This method is called in dialog processing only. This method just inherits from the superclass. DLG_PREPARE_FOR_DIALOG_BTX technical If needed, this method can be reimplemented by partner or customer owned business transactions. This method is called in dialog processing only. This method just inherits from the superclass. DLG_REDO_LOAD Related business requirement: Re of business transaction Loads the redo data (the data maintained in the original execution of the BTX) in the application in dialog mode. This method does not need to be reimplemented. Only the BTX-specific method dlg_redo_load_btxdependent() can be reimplemented. This method is called in dialog processing only. This method just inherits from the superclass. DLG_SHIFT_LOAD Related business requirement: Shift of effective date of a BTX; Revise business transaction data Loads the shifted data (the data maintained in the original execution of the BTX with adjusted dates) or, in case of a revision, the original data in the application in dialog mode. This method does not need to be reimplemented. This method is called in dialog processing only. This method just inherits from the superclass SAP AG or an SAP affiliate company. All rights reserved. 21

22 DLG_REDO_LOAD_BTXDEPENDENT Related business requirements: Re If needed, this method can be reimplemented by partner- or customer-owned business transactions. This method is called in dialog processing only. This method just inherits from the superclass. DLG_SHIFT_LOAD_BTXDEPENDENT Related business requirements: Shift of effective date of business transaction and revision of business transaction data If needed, this method can be reimplemented by partner- or customer-owned business transactions. This method is called in dialog processing only. This method just inherits from the superclass. DLG_SWITCH_REDO_SHIFT Related business requirements: Re, shift of effective date of business transaction and revision of business transaction data This method is called after the Data Transfer button is called during the re or shift of effective date or the revision of business transaction data. It decides whether the successor DLG_REDO_LOAD (re) or DLG_SHIFT_LOAD (shift of effective date) should be called. This method does not need to be reimplemented. This method is called in dialog processing only. This method just inherits from the superclass. DLG_REDO_RESET Related business requirements: Re, shift of effective date of business transaction and revision business transaction data Resets in dialog mode the data to the state before execution of the business transaction. This method does not need to be reimplemented. This method is called in dialog processing only. This method just inherits from the superclass SAP AG or an SAP affiliate company. All rights reserved.

23 DLG_REFRESH_LOGGER Technical Deletes old messages from the logger. This method does not need to be reimplemented. This method is called in dialog processing only. This method just inherits from the superclass. DLG_RESET_ERROR_BEFORE_DIALOG Technical Resets the error flag of the failed keys (execution levels) before displaying the dialog; Otherwise the following activities would not process them. It also resets all provided interfaces and components. This method does not need to be reimplemented. This method is called in dialog processing only. Implementation This method just inherits from the superclass. CALL_TAX_SETUP Related business requirement: Handling of tax relevance of a BTX. Calls set up for the taxation subprocess. All shipped business transactions are prepared for handling taxes. This method does not need to be reimplemented. As mentioned above, the method just inherits from the superclass. CHECK_FOR_CHANGE Related business requirement: Completion of the business transaction should only be allowed if businessrelevant data has been changed. 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. This method just inherits from the superclass. CHECK_FOR_CHANGE_BTXDEPENDENT Related business requirement: Completion of the business transaction should only be allowed if the business-relevant data has been changed SAP AG or an SAP affiliate company. All rights reserved. 23

24 CHECK_FOR_CHANGE_BTXDEPENDENT Must be reimplemented by any BTX. For shipped business transactions, the checks are done in an of a BTX-specific BAdI. In the case of, 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). Check to ensure that such methods are redefined when called. This method can be redefined by BTX. This method just inherits from the superclass. CHK_EXEC_ALLOWED_ON_LEVEL_BTXD Related business requirement: Executability of a business transaction at certain levels 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. This method just inherits from the superclass. CREATE_NEW_STATE_DC_BTXDPNDNT Related business requirement: New state of application is needed for processing during completion of business transaction 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. Creates an instance reference of the BT- specific data container SAP AG or an SAP affiliate company. All rights reserved.

25 CREATE_OLD_STATE_DC_BTXDPNDNT Related business requirement: Old state of application is required for processing during completion of business transaction Stores BTX-specific data at start of BTX in a data container which is passed to 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. 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. Sets values of some BTX control parameters at run time. These values can be overridden or BTX-specific values can be set in get_btxprocctrl_btxdependent(). This method does not need to be reimplemented. This method just inherits from the superclass. GET_BTXPROCCTRL_BTXDEPENDENT Business-related requirement: Sets the BTX-specific values for some parameters that determine the behavior of the BTX. If required, this method can be reimplemented by partner- or customer-owned business transactions. This method is reimplemented by the BTX to set values for additional parameters. GET_REDO_CMD_INIT_BTXDEPENDENT Technical If required, this method can be reimplemented by partner- or customer-owned business transactions. Special issue for a shipped business transaction. Should not be required for customer- or partner-owned BTX. This method just inherits from the superclass SAP AG or an SAP affiliate company. All rights reserved. 25

26 IS_AVAILABLE_BTXDEPENDENT Related business requirement: Availability of a business transaction. BTX-dependent checks for the availability of the BTX. If required, this method can be reimplemented by partner- or customer-owned business transactions. 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? 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. This method just inherits from the superclass. IS_EXECUTABLE_MNDTRY_BTX Related business requirement: Are there conditions where the business transaction is not executable although it is available? 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. This method is reimplemented by the BTX. The check that assures that there is a recurring premium is not mandatory in general, but it is for this BTX. This check should not be overridden, that is why it is done here. IS_EXECUTABLE_OVERRIDABLE Related business requirement: Are there conditions where the business transaction is not executable although it is available? 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. This method just inherits from the superclass SAP AG or an SAP affiliate company. All rights reserved.

27 IS_EXECUTABLE_OVERRIDABLE_BTX Related business requirement: Are there conditions where the business transaction shall not be executable although it is available? 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. 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. Checks from the completion service Customizing if the fund-btx-id differs from NFBTX_ID. If so, funds relevance of the BTX is assumed. This method does not need to be reimplemented. This method just inherits from the superclass. PRE_FINISH_BTXDEPENDENT Related business requirement: Business-related processing steps before completing the business transaction If required, this method can be reimplemented by partner- or customer-owned business transactions. This method just inherits from the superclass. FINISH_BTXDEPENDENT Related business requirement: Finalize business transaction if it can be completed, e.g. provide components. If required, this method can be reimplemented by partner- or customer-owned business transactions. This method just inherits from the superclass. PROCESS_DETERMINE_BTX_DATA Related business requirement: Business-relevant data specific for the business transaction 2016 SAP AG or an SAP affiliate company. All rights reserved. 27

28 PROCESS_DETERMINE_BTX_DATA 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. The BTX data container interface that is used can be generated as well, by the wizard is started in transaction /PM0/ABX_INFGEN. 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. 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 re 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. 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. 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) SAP AG or an SAP affiliate company. All rights reserved.

29 PROCESS_ENTER_BTX_DATA MOD_POLPR() - Changes Contract Data (Basis) MOD_LL_VALID() - Changes Value Date (Life) MOD_LL_PREM() - Changes Premium (Life) 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. The superclass in background mode enters the charges data by calling the method of the charge API class mr_abv_charge_api- >process_polpr_charges(). A separate data container for charges is used for this. This method does not need to be reimplemented. This method just inherits from the superclass. PROCESS_ENTER_COMDIFF_DATA Related business requirement: Alternative commission participants can be maintained for a business transaction. The superclass in background mode enters the commission data by calling the methods of subprocess API class /PM0/CL_ABP_SUB_BTX_COMDIF_AMD: mr_btx_api_sub_comdiff->setup() mr_btx_api_sub_comdiff->init() mr_btx_api_sub_comdiff->process_enter_comdiff_data() mr_btx_api_sub_comdiff->pre_finish() mr_btx_api_sub_comdiff->finish() and so on. To load the data in background mode, a separate data container for commission participants is used. This method does not need to be reimplemented. This method just inherits from the superclass. PROCESS_ENTER_TAX_DATA Related business requirement: Taxation handling is needed for a business transaction SAP AG or an SAP affiliate company. All rights reserved. 29

30 PROCESS_ENTER_TAX_DATA The superclass 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. This method does not need to be reimplemented. This method just inherits from the superclass. PROVIDE_COMPONENTS Related business requirement: Different components in the FS-PM application must be provided with data when completing the business transaction. The superclass provides the following components with data depending on the required flag: Charges by calling /pm0/cl_abp_btx_gt=>provide_charges() Cashflow handling business transaction independent by calling /pm0/cl_abp_btx_gt=>provide_cashflow_bp() Cashflow handling business transaction dependent by calling /pm0/cl_abp_btx_gt=>provide_cashflow_btx() Correspondence by calling /pm0/cl_abp_btx_gt=>plan_corr() This method does not need to be reimplemented. This method just inherits from the superclass. PROVIDE_INTERFACES Related business requirement: The interfaces to other installed applications must be supplied with data The superclass provides the following interfaces with data depending on the required flag: PFO interface by calling /pm0/cl_abp_btx_gt=>provide_pfo() Collections and Disbursements interface by calling /pm0/cl_abp_btx_gt=>provide_cd() Commission interface by calling /pm0/cl_abp_btx_gt=>provide_cs() Claims interface by calling /pm0/cl_abp_btx_gt=>provide_cm() Business Partner interface by calling /pm0/cl_abp_btx_gt=>provide_partner_intf() This method does not need to be reimplemented. This method just inherits from the superclass SAP AG or an SAP affiliate company. All rights reserved.

31 TAKE_SNAPSHOT Related business requirement: Keep parts of the application objects for further usage 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. This method just inherits from the superclass. TECH_CLEANUP_BTXDEPENDENT technical The BTX-specific cleanup work takes place in this method. This method can be reimplemented. Empty, nothing to be done here for this BTX. TECH_SETUP_BTXDEPENDENT technical 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. The wrappers for Basis and LIFE are created. In the standard delivery, this business transaction does not maintain P&C siblings. EXTINCT_CLONE Technical Clean up the clone if there is one. This method does not need to be reimplemented. FS-PM offers the possibility of cloning the business object and working on the clone in dialog mode. This is done for a few shipped business transactions. For partners and customers, we highly recommend avoiding the need to clone the business object. This method just inherits from the superclass Update Relevant for 5.3 SP01 As of FS-PM 5.3 SP01, when setting up a sales product in In-Force Business Configurator you can define whether the 2016 SAP AG or an SAP affiliate company. All rights reserved. 31

32 sales product is allowed for multi-contract processing: When a new business transaction is developed that is to be available at policy level for multi-contract-enabled sales products you must check whether the new business transaction meets one of the following criteria: The business transaction triggers derivations that are executed at or below contract level. The business transaction collects charges or processes tax and subsequently writes dependent journal entries at contract level. If at least one of these criteria is met, the business transaction must not be executed at policy level in multi-contract processing mode because not all relevant contracts will be available in the loaded application. To prevent the execution of the business transaction in such cases deactivate the business transaction using /PM0/CL_ABP_BTX_GT=>CHECK_NO_MULTI_CONTRACT_PROC. In the FS-PM 5.3 SP01 standard shipment, the following business transactions fulfill at least one of the criteria mentioned above and are therefore not executable at policy level in multi-contract processing mode: Change Policyholder Change Commission Participant Change Related Contract Extend TCN Edit Note Edit Reassessment Change Representative Change External Reference Product Change Process Premium Waiver Process Coinsurance Change Organizational Assignments SAP AG or an SAP affiliate company. All rights reserved.

33 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. Note Resolution of postdated business transactions and the re 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. The 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, 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. The 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 SAP AG or an SAP affiliate company. All rights reserved. 33

34 Method: /PM0/IF_ABP_BPU_BTX_BTS~CLOSE_BTX For, this method is called in work step 90 (/PM0/CL_ABP_BTSWS_BPA_CLOSEBTX) of BTS ID BPA_TVR_AMD. Method: /PM0/IF_ABP_BPU_BTX_BTS~INIT_BTX Related business requirement: The business transaction must be initialized in background mode. The of the method initializes the business transaction. The methods: /pm0/if_abp_btx_process~init() (of BTX API) init_btxdependent() are executed here. For, this method is called in work step 40 (/PM0/CL_ABP_BTSWS_BPA_INITBTX) of BTS ID BPA_TVR_AMD. Method: /PM0/IF_ABP_BPU_BTX_BTS~INIT_BTX_CONTAINER Related business requirement: initialization of BTX data container in background mode. The of the method initializes the BTX container. The BTX API method process_determine_btx_data() is executed here. For, this method is called in work step 60 (/PM0/CL_ABP_BTSWS_BPA_INITCC) of BTS ID BPA_TVR_AMD. Method: /PM0/IF_ABP_BPU_BTX_BTS~POSTPROCESSING Related business requirement: After the call of product engine, the calculation results must be handled in background mode. The of the method processes the business transaction after the call of the product engine. The methods: /pm0/if_abp_btx_process~handle_calc_results() /pm0/if_abp_btx_process~pre_finish() /pm0/if_abp_btx_process~get_predate_trigger() of BTX API are executed here. For, this method is called in work step 80 (/PM0/CL_ABP_BTSWS_BPA_POSTPROC) of BTS ID BPA_TVR_AMD. Method: /PM0/IF_ABP_BPU_BTX_BTS~POSTPROCESSING_ERRCS Related business requirement: After the call of the product engine, potential errors must be handled in background mode. The of the method processes the error messages after the call of product engine for the business transaction. The methods: SAP AG or an SAP affiliate company. All rights reserved.

35 Method: /PM0/IF_ABP_BPU_BTX_BTS~POSTPROCESSING_ERRCS /pm0/if_abp_btx_process~handle_calc_errors() /pm0/if_abp_btx_process~get_predate_trigger() of BTX API are executed here. This method is called by the BTS core framework. Method: /PM0/IF_ABP_BPU_BTX_BTS~PREPROCESSING Related business requirement: Before the call of the product engine/completion of the BTX, the data from the persistent data containers must be loaded in the business object and subsequently calculated. The of the method processes the business transaction until the call of product engine. The methods: process_enter_btx_data() depending on the flag: process_enter_charge_data() depending on the flag: process_enter_comdiff_data() /pm0/if_abp_btx_process~calculate() /pm0/if_abp_btx_process~get_predate_trigger of BTX API are executed here. For 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. The of the method sets up the business transaction context. The method: /pm0/if_abp_btx_tech~setup() of BTX API is executed here. For, this method is called in work step 30 (/PM0/CL_ABP_BTSWS_BPA_SETUP) of BTS ID BPA_TVR_AMD 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 the 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: 2016 SAP AG or an SAP affiliate company. All rights reserved. 35

36 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 of the BAdI /PM0/ABP_PROC_DERIVE_BADI. here has the /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. 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 of BAdI /PM0/ABP_PROC_DERIVE_BADI. here has the /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. o For shipped business transactions, partners and customers can implement additional checks by implementing the multi-implementable filter BAdI /PM0/ABP_PROC_DERIVE_CUST_BADI for the business transaction. o For a partner- and customer-owned business transaction, you have some options as to how to implement the checks and derivations in /PM0/IF_ABP_BTX_PROCESS~ PRE_FINISH/CALCULATE. In any case, it is recommended to collect all checks in new business functions as <BTX specific business component>- >do_checks_end. Here, you can also call business functions that are already shipped SAP AG or an SAP affiliate company. All rights reserved.

37 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, 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, this is the BAdI /PM0/ABP_TVR_CHECK_BADI. o For partner- and customer-owned business transactions, the 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 SAP AG or an SAP affiliate company. All rights reserved. 37

38 o The Customizing of the completion service is described in more detail in Customizing of Completion Service Data Container and Filler Classes 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, 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, 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 re, /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 has to ensure that, during the re 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 of the BAdI /PM0/ABP_TRANSFER_CSTM_BADI, which is required to handle SAP AG or an SAP affiliate company. All rights reserved.

39 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: 2016 SAP AG or an SAP affiliate company. All rights reserved. 39

40 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 re/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 re/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 contains the algorithm to get the necessary data and return it to the caller. The DC can either realize its own algorithm to retrieve the requested data or it can be filled from outside. As a consequence of the possibility to fill the data container by an external caller, the DC implements a second interface, the DC SETTER interface that allows the caller to store the data (including the field modifier information). The DC setter and the BTX DC interface should be in sync concerning the data that can be SAP AG or an SAP affiliate company. All rights reserved.

41 stored. Nevertheless they certainly differ with regard to the concrete signatures (for example, data types) and the 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 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 SAP AG or an SAP affiliate company. All rights reserved. 41

42 Note For a business transaction to be available at policy level, you have to enter line of business = BS here (stands for Basis; at policy level, no line of business can be determined). In all other cases, you have to name each LoB explicitly. BS does not mean that a BTX is available for all LoBs, but it is available at policy level. For instance, if a BTX is available at policy level and at contract level, it is necessary to customize BS and each LoB like LL, LP, and so on. Entities and Operations: Here, for each business transaction/line of business, the entities (DB table name) are defined that can be processed, and for each such entity the permitted operation modes Maintained by SAP/partner only. Example In this view, all the entities with input fields on the corresponding business transaction UI need to be maintained. Additionally, you have to specify the operations that can be performed by a user for this entity: creation, modification, or deletion. It is also possible to define a subprocess that ensures that the entity is processed by a subprocess in background mode. o Input Fields: Defines, for each business transaction/line of business/entity, the maintainable fields Maintained by SAP/partner only. o Input Fields Standard Entity (Customer): Defines, for each business transaction/line of business/ shipped entity, additional maintainable fields owned by the partner or customer For use by customers. You can add fields here for shipped entities without need for modification. o Entities and Operations (Customer): Here, for each business transaction/line of business, the entities (DB table name) owned by the partner or customer are defined that can be processed, and for each such entity the permitted operation modes For use by customers. You can add entities here for shipped business transactions modification-free. o Higher-Level Entities/Higher-Level Entities Standard Entity (Customer): SAP AG or an SAP affiliate company. All rights reserved.

43 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 customerowned 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 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 2016 SAP AG or an SAP affiliate company. All rights reserved. 43

44 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 Process Model for Business Transaction This chapter does NOT describe specific issues for process models of subprocesses. We assume that you are familiar with Customizing process models in PBT. Cross-application commands For each business transaction to be executable in dialog mode, you have to create a cross-application command and assign it to the process model of the BTX in PBT Customizing. For a business transaction that shall be reimplementable in semi-automatic mode, you have to define an additional cross-application command SAP AG or an SAP affiliate company. All rights reserved.

45 Example Figure: Cross-application command for regular execution of in dialog mode Figure: Cross-application command for executing in semi-automatic re 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. Caution Both commands are assigned to the same process model, but for the command for re of the business transaction you have to mark the checkbox Submodel SAP AG or an SAP affiliate company. All rights reserved. 45

46 Attributes of process model Example Figure: Attributes of process model P_B_S_TVR_AMD The following attributes have to be maintained for a business transaction process model: Process Model: the name given here is the technical BTX_ID Description Command on Entry: CMD_M_ON_ENTRY. The successor of this command is the first model node to be processed in dialog mode API class: here the API class described in API Class of Business Transaction has to be entered BTS API class: here the BTS API class described in API Class for Executing a Business Transaction in Background has to be entered SAP AG or an SAP affiliate company. All rights reserved.

47 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 SAP AG or an SAP affiliate company. All rights reserved. 47

48 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 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. It is probably useful to check which BTX API methods are implemented by which node Subcontroller Model This chapter does NOT describe the creation of subcontroller models in detail. We assume that the reader is familiar with Customizing of subcontroller models in PBT. For instance, the meaning and Customizing of views and ALV parameters is not explained in this document. Besides the generally valid and reusable system dialogs, such as in the subprocess of reversing a business transaction, a business transaction usually has a specific dialog where the business data relevant for the business transaction are maintained. Thus, a process model of a business transaction commonly has a node which implements the subcontroller model SAP AG or an SAP affiliate company. All rights reserved.

49 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 SAP AG or an SAP affiliate company. All rights reserved. 49

50 Example Figure: The nodes of the subcontroller model (P_B_D_TVR_MOD) The standard nodes are: P_B_MDIA01 P_B_NAVTREE P_B_HEADER P_B_LOGGER If there is a tabstrip, following nodes have to be included: P_B_TAB01 to capture the tabstrips P_B_SCRN01 - P_B_SCRN0X for the tabstrips themselves. Basic settings of subcontroller model If the dialog of the business transaction is to display a button for simulative calculation, in Screen Assignment you should enter GUI status BTX_AMENDMENT_CLT_2 of function group /PM0/SAPLABP_CDM_GUI_STATUS (or BTX_AMENDMENT_REL if the business transaction is to be able to release the application from the business transaction dialog). If not, then use GUI status BTX_AMENDMENT_ENTRY (or BTX_AMENDMENT_ENTREL if the SAP AG or an SAP affiliate company. All rights reserved.

51 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 SAP AG or an SAP affiliate company. All rights reserved. 51

52 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 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 are displayed: SAP AG or an SAP affiliate company. All rights reserved.

53 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 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 SAP AG or an SAP affiliate company. All rights reserved. 53

54 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 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 re, 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 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, these are the PBT process model P_B_S_TVR_EDC and subcontroller model P_B_D_TVR_EDC. For more details, refer to these. Metainformation BTrans Coinsurance/Coll.GrpIns.: As shipped, the Mass Change business process offers the modes Coinsurance and Collective Insurance/Group Insurance; if the business transaction is available for the Mass Change business process, select with these checkboxes the mode(s) of the Mass Change business process where the BTX shall be available. Metainformation Relevant for Updating relevant: In this field, you can maintain the update relevance of a business transaction SAP AG or an SAP affiliate company. All rights reserved.

55 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 In this view, you can assign business processes that are maintained in table /PM0/ABUUBIZPRO to a business transaction. In the above example, is available in in the Change business process only SAP AG or an SAP affiliate company. All rights reserved. 55

56 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 In this view, you should assign all possible processing IDs/journal entries that can be written by a business transaction. It is currently for information only here, but SAP recommends maintaining these entries. Note The processing IDs to be maintained here first have to be entered in the Customizing of journal entries, see Defining Journal Entries SAP AG or an SAP affiliate company. All rights reserved.

57 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 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 2016 SAP AG or an SAP affiliate company. All rights reserved. 57

58 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 class is determined and called. The Customizing for the Completion Service can be found with transaction SE43 under Developer Customizing -> Internal Customizing: Figure: Where to customize the Completion Service class for a business transaction SAP AG or an SAP affiliate company. All rights reserved.

59 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 s: 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: for LOB Life with call of product engine and fundsspecific functions Basisimplementierung: Cross-LOB superclass 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 2016 SAP AG or an SAP affiliate company. All rights reserved. 59

60 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 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 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 is provided. It is used to define the actual business transaction-specific call of insurance mathematics. The Life /PM0/CL_ALP_BC_BTXCONCL_LL and its P&C/Non-Life counterpart /PM0/CL_APP_BC_BTXCONCL_LP, are derived from the basic. 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 s (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 s 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 is defined in a member attribute. A further, /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 "" 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 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 If it is not possible to use one of the delivered classes, proceed with step Copy your chosen class (and the delivered superclasses of your chosen class) to create your own class hierarchy in your namespace. Caution The partner or customer Completion Service should not inherit from /PM0/ classes SAP AG or an SAP affiliate company. All rights reserved.

61 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 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 (LoBdependent) 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, 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 SAP AG or an SAP affiliate company. All rights reserved. 61

62 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 re 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 re (result of step 7 in the recommendation above). This is only required if you really want to write a specific journal entry here. Postdated Processing: The journal entry that is written on successful completion of the business transaction on the call of a postdated application (result of step 7 in the recommendation above). Unit-Linked Processing: Specifies that fund-linked processing is carried out, and its type (result of step 8 in the recommendation above) SAP AG or an SAP affiliate company. All rights reserved.

63 Example The entries for the "" business transaction are: 4.4 IMG Customizing 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 SAP AG or an SAP affiliate company. All rights reserved. 63

64 Define Business Transactions Example Figure: Table entries for Note The business transaction has to be maintained in internal Customizing (see Customizing of Control Parameters of a Business Transaction) before an entry for it can be created here. Most of the information is for display only here, and it has to be maintained in the Customizing for control parameters. Only three checkboxes are editable here. For shipped business transactions, you can change the setting of these three checkboxes modification-free. o Changeable Control Parameters - ExBetContrEnd & TechEnd: You have to mark this checkbox if the business transaction is to be executable between contract end date and technical end date o Changeable Control Parameters - Executable on Exp. Date: You have to mark this checkbox if the business transaction shall be executable on the expiration date of a contract element. o Changeable Control Parameters - Single Execution: If you want a business transaction to be executable more than once for the same contract element within a single business process, you have to deselect this checkbox SAP AG or an SAP affiliate company. All rights reserved.

65 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 Re of Business Transactions The behavior of a business transaction in the context of re 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 Re of Business Transactions (Retroactive Change). The possible options are: No re at all (both checkboxes not marked) Re without user interaction (automatic) Re 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 SAP AG or an SAP affiliate company. All rights reserved. 65

66 Example Figure: Behavior of in re mode The logic of the default 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 res 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 re 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 of the BAdI expects exactly three entries here, one entry for each trigger type. The listed assignments can be combined. The standard of the BAdI evaluates the assignments in the order mentioned above. If several assignments match for a re, 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 Re of Business Transactions SAP AG or an SAP affiliate company. All rights reserved.

67 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 2016 SAP AG or an SAP affiliate company. All rights reserved. 67

68 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 Defining Journal Entries All processing IDs/journal entries that a business transaction is to be able to write have to be customized here: Figure: Customizing activity for defining journal entries SAP AG or an SAP affiliate company. All rights reserved.

69 Example Figure: The three journal entries that 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 re mode is customized. But in the standard shipment this is no longer used. Do not forget to update the Processing ID 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. See the online documentation here for further information. Recommendation If a business transaction can write different journal entries, such as for postdating, the additional information should usually 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. However, for postdated processing the "Commission-Relevant" checkbox must not be selected. This would lead to avoidable run-time consumption as the postdated commission cases are discarded later on. The commission cases are finally created when removing the postdated processing SAP AG or an SAP affiliate company. All rights reserved. 69

70 4.4.3 BTS Customizing If you want to execute business transactions in the background, or if you want to resolve postdating or reimplement a business transaction, you have to define process IDs for BTS dates. See also API Class for Executing a Business Transaction in the Background. You can find the corresponding Customizing views in the following Customizing activity: Policy Management -> In-Force Business Management -> Basis -> Update -> Business Transaction Scheduler (BTS) -> Process IDs for BTS Dates Figure: Where to define process IDs for BTS dates These settings are essential for business transactions: Origin ID of BTS Date: User-defined, recommended naming <BPA_XXX> Text ID of BTS Date: User-defined Parallel Processing Indicator: Set X = yes Processing via Time Model Indicator: Set X = yes Indicator Whether Date Removes Policy Postdating: Set = no Business Process: Always set as P in the context of background execution of business transactions of the Change business process Business Transaction ID: btx_id of business transaction SAP AG or an SAP affiliate company. All rights reserved.

71 Example Figure: Definition of BTS date for background execution of 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 SAP AG or an SAP affiliate company. All rights reserved. 71

72 Example Figure: The work steps for The list of work steps in the example above is the minimum set of work steps required for a business transaction with no call or a single call of the product engine. If the BTX executes more than one call of the product engine, you have to add the required number of subphases with the corresponding /PM0/CL_ABP_BTSWS_BPA_POSTPROC work step SAP AG or an SAP affiliate company. All rights reserved.

73 Example Figure: Work steps of a business transaction with six calls of the product engine 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 SAP AG or an SAP affiliate company. All rights reserved. 73

74 Example Figure: Available and assigned business transactions in the Change business process for template 92H0000S0001 (example) Business Process A business process in which business transaction assignments are available is displayed on the screen. The following business processes can be selected: New Business Display Application Change Universal Change Inquiry Resetting - Initial Screen Resetting - Processing Reversal SAP AG or an SAP affiliate company. All rights reserved.

75 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 SAP AG or an SAP affiliate company. All rights reserved. 75

76 4.4.5 Business Transaction Folders As of FS-PM 5.1, business transaction folders, intended to group business transactions, can be separately defined in two new Customizing activities called Define Business Transactions Folders and Assign Business Transaction Folders to Business Processes. Figure: Customizing activities for defining business transaction folders Define Business Transaction Folders You define a new folder by entering a folder ID and a description SAP AG or an SAP affiliate company. All rights reserved.

77 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 SAP AG or an SAP affiliate company. All rights reserved. 77

78 4.5 Service Enablement of Change Process and Business Transactions As of FS-PM Release 5.3, the 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 steps, especially in the area of PBT Customizing, may not be necessary. In the service enablement of the Change process, a new business object Insurance Policy Change Request has been created. The Insurance Policy Change Request is a new service-oriented of the Change business application which is managed in the Change process of FS-PM. It is abbreviated to IPCR in this document. The API classes and RFCs described in the subsequent sections operate on this new business object. So in this section, when we talk about a Change business application, we are actually referring to an Insurance Policy Change Request 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 SAP AG or an SAP affiliate company. All rights reserved.

79 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 it provides the functionalities that are common to all business transactions. It can create or resume a Change business application, execute a generic business transaction on a loaded Change business application and save or release this application. The Change API enables the service-oriented Change process for postdating. This means: During the start phase of the Change process, when positioning the policy to the effective date of the Change, scheduled processings, postdated processings that cannot be resolved on the current date and on execution of BAdI /PM0/ABP_POLPREDAT_DAYS can trigger postdating. In these cases, a postdated Insurance Policy Change Request is created. During the edit phase of the Change process, only RFCs for business transactions customized as "Postdating" can be executed on a postdated IPCR. An RFC can actively trigger postdating of an IPCR unless a non-postdated business transaction has been executed previously. During the release phase of a postdated IPCR, the same release variant (process type CPT0008) is executed in the same way as in the release of a postdated Change business application in the SAPGUI. Currently the following restrictions apply to the Change process API : The API does not support single or multi-contract processing mode. The API does not support dual control. The API releases a non-postdated IPCR using the same release variant (process type CPT0006 ) as the release of a not postdated Change Business application in SAP GUI. However, some of the release steps executed in this release variant work differently when executed via the Change API. For details please refer to SAP note 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 of method Current constraints 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. Not supported: Single or multi-contract processing Method: /PM0/IF_ABP_SVC_CHG_PROC_API~EXECUTE_BTX Related business requirement: Execute a business transaction in background of method Executes a business transaction on a loaded Change business application in a generic way. The business transaction, now also known as the change type, is given as input. Current constraints Method: /PM0/IF_ABP_SVC_CHG_PROC_API~GET_DEFAULT_SERVICE_DC Related business requirement: Execute a business transaction in background and support extensibility of business transaction 2016 SAP AG or an SAP affiliate company. All rights reserved. 79

80 Method: /PM0/IF_ABP_SVC_CHG_PROC_API~GET_DEFAULT_SERVICE_DC of method Creates the data container instance for the business transaction to be executed. In the case of service-enabled business transactions, 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 of method Releases an application for the business process A (Change). Current constraints Method: /PM0/IF_ABP_SVC_PROC_API~ SAVE_APPLICATION Related business requirement: Save a Change Business application of method Saves an application. Current constraints Method: /PM0/IF_ABP_SVC_PROC_API~ REJECT_APPLICATION Related business requirement: Refuse a Change Business application of method Refuses an application. Current constraints Method: /PM0/IF_ABP_SVC_PROC_API~ RESUME_APPLICATION Related business requirement: Resume a Change Business application of method Resumes an application. Current constraints The remote-enabled function modules to Create an Insurance Policy Change Request Release an Insurance Policy Change Request Refuse an Insurance Policy Change Request Read an Insurance Policy Change Request in external systems are available in the function group /PM0/ABT_SVC_CHGREQ SAP AG or an SAP affiliate company. All rights reserved.

81 4.5.2 The Read API A separate API class /PM0/CL_ABP_SVC_IPCR_READ_API is available to retrieve data from an Insurance Policy Change Request. When retrieving data from an IPCR using the function module /PM0/ABT_SVC_CHGREQ_RTRV. the consumer can specify in detail the data they want to read by providing so called transmission request codes in the import parameter IS_REQUESTED_ELEMENTS. Figure: Overview of transmission request code usage Executing Business Transactions by RFC It depends on the specific landscape and requirements if a RFC should be built in a customer project. From a technical perspective, it is also possible to call the new BTX service API directly in an enterprise service or by NetWeaver Gateway ODATA services. However, for business transactions built by development partners, an RFC is required. In the following diagram, you can see the execution flow of a business transaction. The blue objects are common to all business transactions. The RFC, the BTX service API, the MAP BOX, and the BAdIs are business transaction-specific and must be created for each service-enabled business transaction. The steps are similar regardless which BTX is implemented SAP AG or an SAP affiliate company. All rights reserved. 81

82 Figure: Diagram of interaction RFC - BTX service API and change API for a shipped business transaction Update Relevant for 5.3 SP01 The flow described in the diagram above has been changed as of FS-PM 5.3 SP01. The data container is now created and filled before the execute method of the BTX Service API is called. This change has an impact on the determination of the execution key. The following diagram shows the changes: SAP AG or an SAP affiliate company. All rights reserved.

83 Figure: changes in the interaction pattern for a shipped business transaction End of update for 5.3 SP01 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) SAP AG or an SAP affiliate company. All rights reserved. 83

84 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. The shipped RFCs to execute and simulate business transactions of the Change process can be found in the function groups /PM0/ABT_SVC_CHANGE and /PM0/ALT_SVC_CHANGE BTX Service API The BTX service API orchestrates the calls of the change API for a specific business transaction. The most important methods are: Method: CHECK_PREPARE_INPUT Related business requirement: Perform consistency checks for the input 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 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 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 SAP AG or an SAP affiliate company. All rights reserved.

85 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 Example BTX Service API for Change Beneficiary /PM0/CL_ABP_SVC_BTX_BNF_API Update Relevant for 5.3 SP01 To simplify the development of BTX Service APIs, the interface /PM0/IF_ABP_SVC_BTX_API and the abstract Basis class /PM0/CL_ABP_SVC_BTX_BASE_API are now available. New BTX Service APIs to be developed in the FS-PM standard shipment should use this Basis class. Caution BTX Service APIs to be implemented by customers or development partners shall implement the interface only but not inherit from the Basis class SAP AG or an SAP affiliate company. All rights reserved. 85

86 Figure: Diagram of interface and abstract Basis class for BTX Service API Guideline for the of a new BTX Service API in FS-PM standard development: A new standard BTX Service API class should inherit from the BTX API Basis class /PM0/CL_ABP_SVC_BTX_BASE_API if possible. The new class needs to implement just the following three methods: Create_instance (to get the singleton of the API class) Constructor (to initialize the corresponding variables like mc_btx_id) Set_data_to_dc (to pass on the data from the caller to the data container) Create_instance: The interface has to pass the corresponding BTX Service API class as a returning parameter. A Create_Instance method must not use a generic parameter. Constructor: This method will call the INIT method form the interface and pass on the BTX-Id (for example the BTX Change Benefit / Premium has the BTX-Id P_B_S_BN_PRM_AMD) Set_data_to_dc: This method will have a different set of importing parameters for each BTX. Example You can use the class /PM0/CL_ABP_SVC_BTX_BN_PRM_API as an template for new standard business transactions RFCs The RFCs can be called directly or they 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 SAP AG or an SAP affiliate company. All rights reserved.

87 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 Update Relevant for 5.3 SP01 If the BTX Service API Basis class is to be used, then the Mapbox class must implement the interface /PM0/IF_MAPBOX_SVC_. The interface is only used to set the Policy ID. Example Implementation examples are the classes /PM0/CL_MAPBOX_SVC_BN_PRM and /PM0/CL_MAPBOX_SVC_DDC 2016 SAP AG or an SAP affiliate company. All rights reserved. 87

88 Enhancement of RFCs Provided by FS-PM Standard Product or Development Partners The specific input and output structures must be defined from a business point of view and shall be enhanceable (character-type or numeric). By appending the structure with partner and customer fields, the input is automatically moved to the RFC. If enhancements of the input/output are needed that imply more than field enhancement the EXTENSIONIN and EXTENSIONOUT parameters can be used. For the processing of the EXTENSIONIN parameter, the BAdI method EXECUTE_MAPPING called by the MAPBOX shall be used. For the processing of the EXTENSIONOUT parameter, the BAdI method PROCESS_EXTENSIONOUT, called by the RFC, shall be used. Customers/partners can do their own mapping by implementing the BAdI method EXECUTE_MAPPING. Example BAdI for business transaction Change Beneficiary: /PM0/ABT_SVC_BNFCRY_BADI SAP AG or an SAP affiliate company. All rights reserved.

89 The following diagram gives an overview of the execution of the enhancement options: Figure: Execution of enhancement options in RFC call 2016 SAP AG or an SAP affiliate company. All rights reserved. 89

90 Depending on the type of RFC (operation mode create, update, read, find or retrieve), different enhancement patterns are suitable. For RFCs that perform a read, we do not need to have the ExtensionIN input parameter or the Process ExtensionIN BAdI call since the input is minimal and usually resumes to a technical key. The Process ExtensionOut BAdI call is done at the end of the RFC, so that the customer can enhance the output with their own entities. Figure: Execution of enhancement options in a READ RFC call SAP AG or an SAP affiliate company. All rights reserved.

91 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 2016 SAP AG or an SAP affiliate company. All rights reserved. 91

92 The BAdIs mentioned above are available in the Implementation Guide on SAP Service Marketplace at 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 Example: Execution of Business Transaction through Enterprise Services This section describes where in the system you can find information about the 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 =/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 SAP AG or an SAP affiliate company. All rights reserved.

93 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 SAP AG or an SAP affiliate company. All rights reserved. 93

94 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 by customers. See API Class of Business Transaction and Business Components and Business Functions /PM0/ABP_PROC_DERIV_CUST_ES /PM0/ABP_AMD_CHECK_ES /PM0/ABP_PROC_DERIVE_CUST_ BADI e.g. /PM0/ABP_TVR_CHECK_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 This enhancement spot contains a BAdI for each shipped business transaction for implementing the check for changes. BAdI can be overimplemented by partners or customers. See API Class of Business Transaction and Business Components and Business Functions SAP AG or an SAP affiliate company. All rights reserved.

95 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 re mode. See Customizing of Business Transactions /PM0/ABP_DC_ES /PM0/ABP_BCRDO_ES /PM0/ABP_DC_CHECK_BADI /PM0/ABP_DC_COMPARE_BADI /PM0/ABP_DC_MERGE_BADI /PM0/ABP_DC_INIT_BADI /PM0/ABP_TRANSFER_CSTM_BA DI 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. 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 SAP AG or an SAP affiliate company. All rights reserved. 95

96 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 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 Scenario B In this case, the partner has to implement their own business transaction 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 the partner's own subprocesses for maintaining the input fields of the new entity. Within the partner subprocesses, it is not allowed to do the following: Calculate Call commits Load business objects Start time model functions Use the same names for commands that are already used (names for commands must be unique) Use cross-application commands with the indicator Subprocess = False Call external systems For the integration of partner subprocesses into some dedicated business transactions (such as main axis business transactions), FS-PM provides the following infrastructure: SAP AG or an SAP affiliate company. All rights reserved.

97 init data input work calculate finish sub_start sub_back Partner/Customer init data input work finish 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 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) 2016 SAP AG or an SAP affiliate company. All rights reserved. 97

98 Create process model (subprocess) Implement BAdIs Maintain the developer Customizing activities Configure Control Parameters for Subprocesses and Configure Control Parameters for Business Transactions Create your own data container (including Customizing entries) Create your own dialog First, you have to create your own dialog. For further information, see the FS-PM Enhancement Guide. The pushbuttons are available by using commands. Create subprocess To create your own subprocess, you have to create a class. An example of how such a class should look is class /PM0/CL_ABP_BTX_CDR. Figure: Sample class for Change Creditor subprocess In addition to this, you must also create a PBT model. An example of how such a model should look is the process model P_B_S_CDR_DETAIL (Change Creditor) SAP AG or an SAP affiliate company. All rights reserved.

99 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 SAP AG or an SAP affiliate company. All rights reserved. 99

100 Create your 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. SampleBTX +init() +work() +calculate() +finish() +process_data() <<interface>> IF_SampleBTX +get_sap_entity() +set_sap_entity() 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. Partner/Customer Subprocess +init() +work() +finish() +process_data() <<interface>> IF_Partner/Customer Subprocess +get_partner/customer_entity() +set_partner/customer_entity() Figure: Sample partner data container with interface For example, an additional data container is be implemented for group insurance. FS-PM provides an 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. <<interface>> IF_SampleBTX +get_sap_entity() +set_sap_entity() <<interface>> IF_Partner/Customer Subprocess +get_partner/customer_entity() +set_partner/customer_entity() GroupDC_Sample_BTX_Impl +init() +work() +calculate() +finish() +process_data() Figure: Sample data container for group insurance + partner interface SAP AG or an SAP affiliate company. All rights reserved.

101 We recommend that delegation is used in order to avoid coding for the standard data container. Thus, all methods from standard business transaction will be delegated. You only need your own for the additional data that is required by the subprocess. <<interface>> IF_SampleBTX +get_sap_entity() +set_sap_entity() <<interface>> IF_Partner/Customer Subprocess +get_partner/customer_entity() +set_partner/customer_entity() GroupDC_Sample_BTX_Impl Partner/CustomerDC_Impl +init() +work() +calculate() +finish() +process_data() +init() +work() +finish() +process_data() 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) Scenario D In this case, partners have to implement their own business transaction SAP AG or an SAP affiliate company. All rights reserved. 101

102 SAP AG or an SAP affiliate company. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. National product specifications may vary. These materials are provided by SAP AG and its affiliated companies ( SAP Group ) for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries. Please see for additional trademark information and notices. 3993