Ansicht
Dokumentation

/PM0/ABQ_MIGRATION_TEST - Test Policy Migration

/PM0/ABQ_MIGRATION_TEST - Test Policy Migration

rdisp/max_wprun_time - Maximum work process run time   BAL_S_LOG - Application Log: Log header data  
This documentation is copyright by SAP AG.
SAP E-Book

Purpose

You can use this program to test the data transfer from a legacy system to FS-PM for the Policy business object.

Integration

Prerequisites

  • You have created policies in FS-PM.
  • You have created an internal number range for the Number Range Object /PM0/ABN08 (numbers of policies) to avoid errors occurring during the update of newly created policies. You do this in Customizing for Policy Management under General Settings -> Number Ranges -> In-Force Business Management -> Define Number Range Intervals for Policies. Or choose the transaction SNRO.
You have stored the number range interval for this number range in the Customizing activity Choose Sales Product-Dependent Number Range Intervals, in the External NR Policy field (/PM0/ABU_PNRIVS-NRRANGEEXP_ID).
Alternatively you can redefine the method GET_NEXT_NUMBER in the local class LCL_VISITOR and program your own external number range logic. For more information, see the Example below.

Features

This program reads the data of an existing policy in FS-PM and formats it for data migration. The data is formatted either as a text file or directly for the call of function module /PM0/ABQ_POL_MASSMIGR.

The format of the data in the text file is compliant with that expected in Legacy System Migration Workbench (transaction LSMW). In LSMW, the record types of the source fields must contain, as the identifying field content, the name that is found at the start of the corresponding row in the created text file. For example, if the identifying field content for the BAPI control parameter were /PM0/BAPI_ABQ_MIGRATION, then this would be /PM0/ABQAPOLICY for the policy header.

This program is an example only, and makes no claim to be complete.

It shows the project team how data from a legacy system needs to be formatted to allow successful migration to FS-PM.

This program simulates data migration by creating one or more copies of an existing policy.

Selection

  • Policy Number
Enter the number of a policy created in FS-PM (preferably not a migrated policy), which is to be used as a template or reference for the new (migrated) policy to be created.
  • Execute Migration
The program reads the data of the template policy and converts it to the corresponding table for the call of data migration.
The program calls function module /PM0/ABQ_POL_MASSMIGR with the data created, and the function module saves the unchecked data to the database (raw data).
  • Create Migration File
    The program reads the data of the template policy and downloads it to a text file. This file is used as an input file for LSMW. This is the basis for data migration from the legacy systems envisaged by SAP. LSMW transfers the data from the input file to IDOCs, which then save the data in the system using function module /PM0/ABQ_POL_MASSMIGR.
  • Display Data
The program reads the data of the template policy and converts it into migration data. The resulting data is only displayed on the screen. It is not processed.
  • Separator for Migration File
The program uses the selected separator to create the migration file to separate the attributes.
  • No. of Policies to Be Created
You can specify the number of new policies to be created from the template.
  • Migrate Reversal
Any reversal executed in the template policy is not converted as a policy version, rather it is extracted as a BTS date and converted as such into the corresponding migration structure.
  • Migrate Premium Waiver
Any premium waiver executed in the template policy in the Life line of business is not converted as a policy version, rather it is extracted as a BTS date and converted as such into the corresponding migration structure.
  • Migrate Distribution Plan
The distribution plan stored for the policy is also migrated.
  • Apply Defaults
The defaults defined in In-Force Business Configurator are also read and used (Check and Derive logic on initialization of the business object).
  • Execute Validation
  • If you select this checkbox, the validation will be started immediately after the raw data is updated to the database.

  • If you do not select this checkbox, the data is written unchecked to the database (raw data), and you must validate and release it in a second step. To execute validation and release, use transaction /PM0/ABQ_FP_Q_POLVAL.

In live migration, you should execute the two steps (posting of raw data and the validation/release) separately for performance reasons.
  • Release
  • If you select this checkbox, the program returns a successfully validated policy for immediate processing.

  • If you do not select this checkbox, you must release a successfully validated policy in a separate validation run.

This checkbox is relevant only if you have also selected the Execute Validation checkbox.
  • Delete Temporary Data
On the migration of policies, the system saves temporary policy versions in the database tables of FS-PM. After successful validation, this data must be deleted again from the database, otherwise you are not able to edit the migrated policy.
Note: This checkbox is relevant only if you have also selected the Execute Validation checkbox.

If you do not want the program to delete the data from the database, you must execute the Delete Temporary Migration Data of Policies program. On the SAP Easy Access screen, choose Policy Management -> Migration -> Policies -> Delete Temporary Migration Data of Policies.
If method CHECK_DELETE_TEMPDATA of the Business Add-Ins (BAdI) BAdI: Functional Validation of Policies - Settings( /PM0/ABQ_POL_VAL_CNTRL_BADI) is implemented in such a way that the temporary migration data is to be deleted from the system after completion of the functional validation, then the temporary data will be deleted in the validation even if this indicator is not set.

In Customizing for Policy Management, choose General Settings -> Migration -> Business Add-Ins (BAdIs) -> Policies -> BAdI: Functional Validation of Policies - Settings.
  • Display Empty Fields
If you select this checkbox, the program displays the empty fields of the migration structures (with initial value) in the output list.

Thus you display which fields are available in the migration structures.
  • Display Descriptions
  • If you select this checkbox, the program displays the corresponding ABAP Dictionary descriptions for the fields of the migration structures.

  • If you do not select this checkbox, the program displays only the migration fields and their contents without the descriptions.

Standard Variants

Output

The program displays the policies created together with the individual fields of the migration structures and their contents.

In a log file, the program lists any errors that occur (under the Execute Migration radio button). Successfully updated policies are displayed in the output list.

Activities

If you select the Execute Migration checkbox, you can choose a generated policy number in the output list and access the policy as follows:

  • If you select the Execute Validation checkbox, you go to Change.
  • If you do not select the Execute Validation checkbox, you go to Inquiry.

In policy validation, you can use control parameters in the /PM0/ABQ_VALIDATION_CNTRL structure to define whether specific steps are to be executed and, if so, how they are to be executed.

In test environments, you can use the following three parameters to define how test migration is to be executed:

  • /PM0/ABQ_VALCNTRL1TO: Defines the date up to which versions are to be validated according to the settings of /PM0/ABQ_VALCNTRL1.
  • /PM0/ABQ_VALCNTRL1: Defines the validation steps to be executed for versions that are before /PM0/ABQ_VALCNTRL1TO (inclusive). By specifying X in position n, this means that step n is to be executed, and by specifying - in position n determines that a step is not to be executed.
  • /PM0/ABQ_VALCNTRL2: Defines the validation steps that are to be executed for versions that are after /PM0/ABQ_VALCNTRL1TO (exclusive). By specifying X in position n, this means that step n is to be executed, and by specifying - in position n determines that a step is not to be executed.
  • The parameters /PM0/ABQ_VALCNTRL1 and /PM0/ABQ_VALCNTRL2 are only evaluated if the user parameter /PM0/ABQ_VALCNTRL1TO is filled with a date.

For more information about the parameters, see the documentation of the BAdI: Functional Validation of Policies - Settings (/PM0/ABQ_POL_VAL_CNTRL_BADI).

  • Example

Create a local class in the program that inherits from class LCL_VISITOR, for example
CLASS ZLCL_VISITOR DEFINITION INHERITING FROM LCL_VISITOR.

Use either an implicit enhancement spot or the customer report ZPM0_TEST_LEGACY_MIG_ICL (you need to create this as a report of the type INCLUDE) for the class definition. The Z report is integrated in the coding.

Now create the following FORM routine (in the enhancement spot or the Z report):

FORM zz_set_type_visitor CHANGING CV_TYPE TYPE STRING.
CV_TYPE = 'ZLCL_VISITOR'.
ENDFORM.

This form is called from the report before the instantiation of class LCL_VISITOR. Instead of the standard class LCL_VISITOR, an instance of ZLCL_VISITIOR is now created and called (including your redefined methods).

The same enhancement technique is also available for the local class LCL_MIGRATION. To instantiate any class you create that inherits from LCL_MIGRATION, create the following FORM routine:

FORM zz_set_type_migr CHANGING CV_TYPE TYPE STRING.
CV_TYPE = 'ZLCL_MIGRATION'.
ENDFORM.






BAL_S_LOG - Application Log: Log header data   PERFORM Short Reference  
This documentation is copyright by SAP AG.

Length: 15047 Date: 20240419 Time: 041854     sap01-206 ( 179 ms )