XML Application Implementation Issues
XML Version 4.0+ Differences when Updating an Existing Application
Version 4.0 represents a major expansion of elements allowed in Origination Update and Underwriting. It allows all the same elements as are allowed in Origination web services. However, some elements may not be used in the context of updating an existing loan application (just like the Origination web pages). Specifically:
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:
Manually Specifying Delete-and-Insert Logic for Some Table-Level Elements
Although delete-and-insert logic doesn’t happen automatically in XML 4.0+ anymore, some table-level elements allow manually requesting delete-and-insert logic by giving action="deleteall" on the first occurrence of the element in the application. This allows remaining occurrences (of that same table-level element in the same application) to specify action="insert". This eliminates concern as to whether or not inserted elements’ prime keys match pre-existing prime keys on the SBA’s database. But consult the XSD to see whether action="deleteall" is allowed. Initially, only table-level elements that consist entirely of prime keys allow action="deleteall" (BorrowerRace, BusAppr, PrincipalRace, SpecialPurpose and UnderservedMarket).
For example, suppose an app currently has special purposes AGRI and EXPT, but you want AGRI and REVL:
<SpecialPurpose action="deleteall"/><SpecialPurpose action="insert"><SpcPurpsLoanCd>AGRI</SpcPurpsLoanCd>
</SpecialPurpose>
<SpecialPurpose action="insert"><SpcPurpsLoanCd>REVL</SpcPurpsLoanCd>
(Without the initial action="deleteall", the insert of AGRI would have resulted in an “already exists” error.)
After XML or JSON changes have been applied
After the XML or JSON updates have been applied to the loan application, the application is validated for approval according to usual business rules. If the application fails validation, the XML or JSON changes are committed to the SBA’s database, which leaves the application updated and still in Application In-Process status.
But if the application passes validation, its status advances according to all the standard SBA business rules for the loan application. If its processing method requires credit scoring and it hasn’t already been credit scored, it goes into the queue to be credit scored. If its processing method and lender agreements require SBA underwriting, it goes into an In Review status. And so on.
In other words, except for processing the XML or JSON, and associated updates to the SBA’s database, OrigUpdate is exactly analogous to pressing the Submit button at the top of the Loan Origination web pages.