Posting a File

Objectives

After completing this lesson, you will be able to:
  • Describe the basic steps of the APM posting process
  • Identify the type of validations performed in the posting process
  • Post a Broker File
  • Resolve posting errors

Posting Process Overview

The term Posting refers to a group of 83 sequential tasks that transfer the data in the integration tables (InCustomer, InBroker, InTranHead, and so on) to their associated configuration tables (Customer, Broker, TranHead/TranHis, and so on). Posting can be performed via InFile Posting or InEntity Posting. InFile Posting operates on an individual file, while InEntity Posting operates on all files in the system. Records within an InFile with a status of Ready or Error will be processed when the Posting process is invoked.

Unposting is the reverse of the last post process, or up to all previous post processes for that Infile. Unposting takes into account any subsequent changes to the records previously posted.  

Tasks of the Posting/ Unposting Process

To view the tasks of a specific posting process, select the dropdown next to the page title and scroll down to Post History.

The PostHistory screen will display all attempts to Post and Unpost for a specific InFile.

Select the row that you want to review and the Runlist Detail Screen will be displayed.

Select the Tasks icon to bring up the Tasks screen and the list of Posting Tasks.

Note

You may need to expand the Completed Tasks section to reveal the specific tasks.

In the Completed tasks section, you will see each task that was executed as well as Start and End Dates/Times and Task Duration. In the example below, we can tell that Customer records since they were posted assigned a RunId.

If there are no associated records in the InFile for the specific posting task, the task is not assigned a RunId and the task is skipped. In the screenshot below, the InFile being Posted did not contain any InCertificate, InProLicense, InProAppointment on InProBackground records, so these tasks were skipped.

The tasks of the Posting process can be broken down into three categories:

  1. Posting: Records are pushed from the InTables to the Production tables. For example: InCustomerPosting: InCustomer to Customer
  2. PostInitialization: Used when records require some preprocessing prior to being posted. For example, In the task InCustomerPostInitialization, the InCustomerNo. CustomerNoMaster field is updated as part of the posting process prior to the InCustomer record being posted.
  3. ProcessEventBefore/After: Used for the configurator to inject custom logic such as SQL Scripts or Batch Entity Updates, or to trigger processes such as Reports or Extracts into the posting process to satisfy business requirements.  For example ProcessEventAfterPost is the last task that is executed as part of the posting process. In this task, a report summarizing the Post Process can be created, triggered, and delivered to the business.

Validation During Posting Process

There are four built-in validation checks during the posting process.

  1. Data Type: Prohibits posting alpha characters into a numeric field
    • In the event the Production data type is configured to be different than the associated InFile field in the schema.
    • In the event logic is executed that changes the field during the Posting Process (Field default or other configuration) in the schema.
  2. Data Length:Prohibits posting a field longer that specified in the database schema.
    • In the event the Production data type is configured to be different than the associated InFile field in the schema.
    • In the event logic is executed that changes the field during the Posting Process (Field default or other configuration) in the schema. 
  3. Foreign Key:Prohibits posting a record that references another entity field that has not be posted yet. For example, the BrokerVendor record for Broker123 is posted establishing the relationship with Vendor ABC effective 1/1/2022.  If Vendor ABC has not been established in the  Vendor table in APM, then this record will fail posting.
  4. Code Types: Prohibits posting a record with an invalid value for field that has an assigned Code Type. For example, Customer.CustomerType has assigned CodeType of G (Group) or I (Individual). If InCustomer.CustomerType is anything other than G or I, the record will error on posting. Additional validations can be manually added via the Entity Edit functionality.

Additional validations can be manually added via the Entity Edit functionality.

Record Matching During Posting Process

As a record is being processed during posting, APM contains logic to determine if the record is to be inserted or is an update to an existing record. In most cases, if the EntityId on the incoming record matches an EntityId (for example, InCustomer.CustomerId = Customer.CustomerId), it is considered a match and will update the Production record. Otherwise, a new record is created.

Some entities have an optional configuration that allows multiple entries for a single parent entity. For example,a Broker can have more than one active BrokerDetail record if the process.match.brokerdetailoption is configured.

In the example below, if an incoming InBrokerDetail record comes in with and matches on BrokerId, EffectiveDate, Match8, Match1 and BusinessType, then the existing BrokerDetail will get updated. Otherwise a new BrokerDetail record will be created. To find available entities with configurable match rules, navigate to the Administrator Portal, then Configuration > Options and search for process.match.

Note

Trying to unpost an InFile could take much longer than expected if a long time has elapsed since the file was originally posted.

Exercise: Manually Post a File

Business Example:

In this exercise, you will manually post the file you imported in the previous exercise.

ExerciseStart Exercise

Steps

  1. Manually post the imported file

    1. In the Portal menu, navigate to Integration > Inbound Data and select File Search.

    2. Select the TrainingCustomer record.

    3. Review the Import Requests for Errors that need to be acknowledged (error status)

    4. Click the Acknowledge hyperlink next to the error.

    5. Enter the comment: Error has been corrected and select OK.

    6. Select Ready.

    7. Select OK.

    8. Select Post, then OK on the confirmation popup screen.

Resolving Posting Discrepancies

When a record fails during posting validation, a discrepancy is created and the InFile records are changed from Ready (ProSta = 1) status to Error (ProSta = 9) status. There are two options to approach fixing any errors:

  • Fix the error directly in the Detail screen of the record and post the data.
  • Fix the data in the source file, then re-import the data. You can approach this option in one of the following ways:
    • Fix the data and only include the fixed records in the source file. The next time the application pulls the data from the source file, the posting process will update only these records. In this scenario, you don't need to unpost and then post the data
    • Fix the data in the source file, but keep all of the records, even the ones without errors, in the source file. In this scenario, because all of the records are being re-sent, you must first Undo Post. Next, purge the relevant Import Request and create a new one.

Exercise: Manually Resolve Posting Discrepancies on Imported Records

Business Example:

In this exercise, you will find the errors on imported records and correct them in the user interface before re-posting.

Prerequisites

Steps

  1. Find the import errors.

    1. Select Integration > Inbound Data > File Search.

    2. On the File Search screen, select the CustomerImport record.

    3. On the File Detail tab, the numbers in the Statistics table are hyperlinks. Select the link (represented as a red number) in the Error column.

      The list of records with errors is displayed.

    4. Select a record to view its Detail screen.

    5. At the bottom of the screen, the Discrepancy message displays the reason for the error. In this case, the Customer Type is a required field.

  2. Fix the error on each customer record.

    1. Scroll up to the customer detail.

    2. Change the Customer Type to Individual.

    3. Select Save.

    4. To return to the list of customers, select Customer Search.

    5. Repeat this step to update the Customer Type for all 12 customers.

  3. Post the file.

    1. Select Post.

    2. Select OK at the popup confirmation screen.

    3. Verify that all records have a status of Posted.

      Note

      If the errors still appear, select Refresh.

    4. In the Portal menu, navigate to Manager - Customers and select Search to confirm that the posted records are in the Customer table.

Exercise: Unpost the Customer File

Business Example:

In this exercise, you will unpost the file you created in the previous exercise.

ExerciseStart Exercise

Steps

  1. Unpost the TrainingCustomer file

    1. From the Portal menu, navigate to Integration → Inbound Data and select File Search.

    2. Select the CustomerImport file.

    3. Select Ready.

    4. Select Undo Post.

    5. Select OK.

      Note

      If records have been successfully posted at different times without being reversed, you will be given the opportunity to incrementally unpost records in reverse order of 

Log in to track your progress & complete quizzes

Learning

SAP FacebookSAP YoutubeSAP LinkedIn