XML 4.0+ Action Attributes and “Prime Keys”

A problem with the automatic delete-and-insert logic of version 3.8i, described above, is that, under its own rules, a “delete all” cannot truly be done. For example, if there’s only one injection item, and that item is no longer part of the application, there’s no way to delete it. In order to trigger the pre-deletion of all injection, you would have to give an <Injection> element. And once you do that, under delete-and-insert logic, you’re inserting a new injection item. Under version 4.0+, delete-and-insert logic no longer happens automatically.

Beginning with version 4.0, Underwriting and Origination Update web services can control deletion, insertion and update of table rows explicitly, manually, with the action attribute. This technique will be very familiar to users of the Servicing web service (now called Servicing2, see Method Servicing2), which has always used action attributes. Every table-level element is allowed to have an action attribute, whose value is generally “delete”, “insert” or “update”. In web services that can only create a new application (such as Originate3 or OrigScore), “insert” is assumed and need not be given on table-level elements. But web services that operate on existing applications (such as Origination Update or Underwriting), the action attribute assures that the sender and receiver are “on the same page” as to what should be done with the data.

Beginning with version 4.0, almost all table-level elements contain identifying column-level elements, called “prime keys” meant to distinguish the real-world person or thing to which it refers. For example, in SBA_ETran XML, every participant (<Borrower>, <Guarantor> or <Principal>) is identified by 2 prime keys: <TaxId> and <BusinessPersonInd>. A borrower person is distinguished from a borrower business with the same TaxId. For example, a sole proprietorship is a business, which is distinguished from the person who has the exact same TaxId.

Action attributes interact with prime keys (if any) to determine whether a miscommunication has occurred:

When inserting a table-level element, its prime keys must not match a pre-existing row on the SBA’s database (for the same application and table). If it does, it’s an error that should be investigated.

When deleting or updating a table-level element, its prime keys must match a pre-existing row on the SBA’s database (for the same application and table). If not, that kind of error must also be investigated.