Component Elend
The Electronic Lending component ELend is the flexible interface to all web services that create or modify loan applications and loans.
The interface to a Web Service is defined using Web Services Description Language (WSDL), a cryptic format for humans, but one readily understanble to Web Services software. The WSDL file for E-Tran is at this URL (link opens a new window):
https://catweb.sba.gov/elend/ws/elend.wsdl.
- The lastest XSD for Loan Origination is: SBA_ETran.8.1.orig.xsd (or use SBA_ETran.curr.orig.xsd ).
- The lastest XSD for Loan Servicing is: SBA_ETran.8.1.serv.xsd (or use SBA_ETran.curr.serv.xsd ).
- Previous XSD for Loan Origination:
- Previous XSD for Loan Servicing:
SBA XSDs make use of the XSD inclusion feature to define shared element types.
- General element types used by any SBA XSD are defined in: SBA_SimpleTypes.xsd.
- E-Tran-specific element types are defined in: SBA_ETranTypes.xsd.
ELend was derived from the Electronic Transfer component ETran, the legacy interface. ETran still exists for existing clients, but is now deprecated for new web service client development. Behind the scenes, both ELend and ETran run the exact same code. ELend and ETran are just different paths of entry into the same code. But ELend is much more flexible, because of its “structure-in/structure-out” design.
A structure is an arbitrarily large collection of name/value pairs. ELend has only one input, called the Inputs structure, which contains both the web service name and all data that service requires. And it has only one output, called the Outputs structure, which returns multiple kinds of information independently. This design frees ELend’s web services from the constraints of WSDL. Since its creation, ELend hasn’t required any new WSDL modifications, even to create new services.
To avoid confusion between the Inputs structure and the values it contains, it’s convenient to refer to the name/value pairs as “keys” rather than “inputs”. The most important key is MethodNamePhysical, the name of the web service itself. All other keys are dependent on MethodNamePhysical.
So, for example, if MethodNamePhysical is “PasswordUpdate”, one might expect another key called NewPassword. But if MethodNamePhysical is “ExtractOrigination”, one might expect another key called ExtractOptions. In structure-in/structure-out design, the list of keys expected in the Inputs structure are what actually define the web service, not the WSDL.
In addition to MethodNamePhysical, all ELend services require the keys CLSUsername and CLSPassword, which identify a CapAccess Login System (“CLS”) account authorizing the caller to use that service. All other keys of the Inputs structure are completely as-needed by the service. Theoretically, they’re independent of keys passed to other services. But there has been some effort into making the key names consistent and easy-to-remember when similar information is needed by different services.
As alluded-to above, there’s only one output for all services in ELend, called the Outputs structure. In general, but not necessarily, its keys are:
|
|
|
|
If the service call was successful, the ErrorMessage keys will be the nullstring. If not, it means the service failed and other keys probably can’t be trusted. When corresponding with the SBA about an error, please email as many of these key fields as are available, because one doesn’t know in advance which information will be most helpful.
Successful call responses are generally encapsulated as XML or JSON in ResponseData. If the client application has the means to parse an XML response, useful information is generally available there for the application to present to the loan officer (and/or saved to the lender’s database, and/or emailed, etc).
The latest XSD for OriginateStatus response is: SBA_ETran_OrigStat_Response.xsd