Posting a File

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.  

To view the tasks of a specific posting process, navigate to the far right of the InFile Detail screen and Scroll down to select 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.

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 were posted since it was 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.

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.

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.

When a record fails 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.