application submission guide - illion

Application Submission Guideillion.com.au
Private and Confidential
The content of this document is copyright and contains confidential information which is the property of illion Software Solutions. No part of this document may be copied, reproduced, transmitted, stored in a retrieval system or divulged to any other party without prior written permission of illion Software Solutions.
© illion Pty Ltd
illion Software Solutions Level 4, 990 Whitehorse Road Box Hill VIC 3128
2
Getting Started ................................................................................................................................. 5
Extract the information from the body of the response.Inteport ................................................... 5
Engine ........................................................................................................................................... 5
Building an XML Request ...................................................................................................................... 6
XML Basics ........................................................................................................................................ 6
Request ......................................................................................................................................... 7
Handling an XML Response ............................................................................................................. 14
Response Pushback ......................................................................................................................... 15
Appendix C – Service Implementation and WSDL ................................................................................ 26
Appendix D – Document History ......................................................................................................... 28
3
illion Decisioning illion Decisioning is the latest high-end decisioning tool available within the Australasian marketplace.
By taking advantage of modern technology and design approaches, illion Decisioning is a completely new application designed to provide significant business functionality. Expected functionality such as completely dynamic flow configuration and total control over all parts of the system are complimented by significant advancements such as allowing customers to manage screens internally and expand the overall system functionality.
illion Decisioning provides a powerful solution that provides businesses with the following key functions:
• The power to change the rules and decision flow to suit changes in the credit process
• Internet based access to the flow configuration allowing easy updating and migration of changes
• Improved customer service through improved control and performance
• Reduced implementation stress through standard interfacing options
• Access to multiple credit bureaus and simple switching between providers
4
Introduction Overview This document provides information about connecting to illion Decisioning through a custom front- end application. The document focuses on three key areas:
• Building up an XML document to be sent as a request through Inteport
• Using Inteport (web service) to connect to the illion Decisioning Engine
• Handling responses returned through Inteport
illion provides:
• illion Decisioning schemas
• Sample request and response xml documents
Assumptions This document is intended for use by organisations that intend on implementing a custom front-end solution to illion Decisioning.
We assume the developer has a reasonable understanding of:
• XML
• An appropriate web based programming language
Rebrand from Inteflow to illion Decisioning We have changed the Inteflow brand to illion Decisioning. The rebranding transition includes a refresh of the corporate branding in documentation and online, as well as within the user interface of the product. However, some technical aspects of illion Decisioning will still refer to Inteflow.
5
Getting Started The illion Decisioning solution is made up of a number of separate components that are deployed together. The following diagram displays the interaction between the main system components:
Figure 1 – The illion Decisioning Solution
The steps below broadly describe the procedures for working with the illion Decisioning solution:
1. Extract data from your system and build an XML request.
2. Include the correct authentication information in the request
3. Send the request to Inteport using the URL provided by illion Software Solutions.
4. Inteport will forward the request to the Engine.
5. The Engine will perform the decisioning process and build an XML response
6. The Engine will return the response to Inteport
7. Inteport will forward the response back to you
Extract the information from the body of the response.Inteport All connectivity into the illion Decisioning system is protected by the Inteport web services. This application is web service based and handles all requests into the Engine.
Engine The heart of the illion Decisioning solution is the Engine. This system handles the processing of the decision logic against each application. It also connects to any external data sources, such as credit bureaux to retrieve additional data to be used in the assessment.
Database (Oracle or SQL Server) The Engine connects to a relational database which holds configuration information and is also used to store each request.
6
Building an XML Request XML Basics A request is made up by a collection of standard XML tags within an XML document. Some tags are containers for more XML tags/containers.
The XML document which is eventually passed to the Engine is a logical grouping of XML tags/containers.
Figure 2 – Sample XML Tag/Container Structure*
* Not a complete example of an illion Decisioning request
When a request is sent to the Engine, an XML schema is used to ensure that the request is properly structured. If the request is deemed to have a valid structure, the Engine then proceeds to validate the input data.
The XML schema will validate the input data based on the following conditions:
• The element is/is not mandatory
• Elements are of the correct data type (string, int, etc)
• The element contains a value as defined in a bound enumeration file
7
If any data is found to be invalid, then the request is rejected and an error response returned. It is possible to extract the details of the error from the response.
In order to prevent the Engine from rejecting your request, you should be aware of illion Decisioning’s validation requirements. An XML schema will have been provided to you. This schema is self- documented and provides all the information required for determining if your request is correct before submission.
illion Decisioning XML Request The illion Decisioning XML request structure is divided into 3 distinct sections. Each of those sections is encapsulated within the Inteflow XML tag.
• Section one is the request container which stores logon data.
• Section two is the application details container which holds data about the application that is being submitted.
• Section three is the service container and contains all data relative to the applicant and their application.
Figure 3 – Inteflow Containers (high level)
Request Each request sent to illion Decisioning must have an initial container labelled ‘request’.
The request container holds all the elements necessary for storing logon and connection details.
Figure 4 – Sample XML Request Container
8
The request container itself takes an attribute (cd_type) which is mandatory. This attribute is used for determining what happens to a request when it is submitted. The three types of submissions are listed below:
Submit Application Application submission occurs where a new request is made to the system for an application to be processed. This can be entered directly into the Inteport web service from an external application. This is the most common request made into the illion Decisioning system.
Figure 5 – Submit Request
Figure 6 – Resubmit Request
Action Application Actioning an application occurs when a manual decision is required to be made to the application. In this case the user may select to change the status of the application or to continue further processing of the application.
Figure 7– Action Request
Request Elements This section describes the elements within the request container. Table 1 – Request Elements
Name Element Comment Mandatory
Operator Id id_oper The id of the operator who is submitting the request.
Yes
Operator Password
tx_password The password for the operator who is submitting the request.
Yes
Service Type cd_service The same as the ‘cd_type’ attribute stored within the request container. This value is upper case. This element is restricted and uses an enumeration list.
Yes
Product Id cd_product A value indicating which decisioning solution to use. The Engine is the only possible selection.
Yes
9
* Although the schema does not require the element, every effort to include all details should be made
Application Details The application details container is used for capturing data about the application being submitted. Figure 8 – Sample XML Application_Details Container
This element is restricted and uses an enumeration list. The default value is ‘IFE’
Channel Id id_channel The id of the channel that the submitting operator resides in. This element is bound to an enumeration include file
Yes
Company Id id_company The id of the company that the submitting operator belongs to.
No*
Merchant Id id_merchant The id of the merchant that the submitting operator belongs to.
No*
Country Id cd_country The country code for the country in which the company resides This element is bound to an enumeration include file.
No*
Service Id cd_security Used for log-in support This element is restricted and uses an enumeration list The default value is ‘IFE’
No*
10
Application Detail Elements This section describes the elements within the application details container.
Table 2 – Application_Details Elements
Name Element Comment Mandatory
Credit product id_product_credit Identifies the Credit Product to be used for the application. This will be used to identify the flow id (below).
Yes
Flow Id id_flow The id of the decisioning flow to be used for the application. If not supplied, this will be determined by the Credit Product (above)
No*
Internal Reference Id
id_reference_internal Applications are assigned an internal reference number on submission. Number will be auto-generated on submissions of type; submit. A client may insert their own number, which will override the auto-generated number. The unique internal reference needs to be re-used for submissions of type; resubmit, action.
Yes
id_reference_external An application reference number that accepts a client’s unique application number.
No
Merchant Id id_merchant_submit The id of the merchant doing the submitting.
Yes
Operator Id id_operator_submit The id of the merchant doing the submitting.
No*
Merchant Id id_merchant_contact The id of the merchant to contact. Not necessarily the merchant who is submitting the request.
No*
Operator Id id_operator_contact The id of the operator to contact. Not necessarily the operator who is submitting the request.
No*
Schema Translation Name
nm_schema_translation This element can be used to define a schema to be used in translating the response. This will override the
No
11
* Although the schema does not require the element, every effort to include all details should be made.
Service The final container is used for storing the application details. These details may include but certainly not be limited to:
• Product details
• Personal details
• Address details – Where an application may have multiple applicants, this container should be duplicated for each.
• Employments details
• Identification details
Note: It is important to note that the application details to capture will be specific to your organisation. Additionally you will have been supplied with an XML schema used to validate the details your organisation is choosing to capture.
With the experience gained from using the schema to build up the request and application_details containers, use those same principles to closely follow the schema and build up the service container. There is however a few key notes to remember:
The Service container is actually used to hold an additional two containers. The first is the action and the second is the application container. The application container is the only one that is initially required in order to process a request. However if an action is performed on an application then the action container will be required.
When an application is processed, a result element is appended at the end of the list of elements in the application container. This element must be stripped off if you wish to resubmit the application.
After the request has been processed the response is generated. The response is simply an edited version of the initial request. The service container as it was named in the request is changed to
default response translation schema
Sequence No no_sequence A number representing the application sequence in a number of submissions. Initial submission will give a sequence of 1 Successive resubmissions and actions will increase sequence by 1 each time
No*
12
response. Some new elements are added to the response container. Also the request and application- details containers are removed.
Figure 9 – Service Container (high-level)
Sending a Request to illion Decisioning Connecting to Inteport to send an XML request is a very simple task.
What is required is a small amount of web service know-how; an understanding of how to connect to and consume a web service in a chosen programming environment.
You can access a list of all available Inteport web services locally by navigating to the following link in your web browser:
http://[Inteport URL]/Inteport/DecisionGateway.asmx
If an Inteport installer was provided then the Inteport URL will be the location at which you installed Inteport. Otherwise you will need to contact Decision Intellect in order to acquire an external Inteport URL. For testing purpose it is possible to use the following web address:
http://test.inteflow.com.au/Inteport/DecisionGateway.asmx
13
If the Inteport URL you have navigated to shows a list of web services, as in figure 10, then you are on the right track.
The list of web services available to you is quite extensive. The only one that is required however is; ExecuteRequest. It is this web service that will handle passing an XML document to Inteport. A full web services description language (WSDL) is provided for your reference in Appendix C.
At this stage all further work will be done in code. As previously mentioned, how you choose to consume the web service will be decided upon by the programming language you are using.
These following steps and sample code are how this task would be accomplished in Microsoft Visual Studio .NET, and are provided as a guide only.
Steps to add a web service:
1. Add a web reference to your project. This web reference will use the URL as discussed above.
2. Add the ‘ExecuteRequest’ web service found within the web reference.
3. In your code header make a reference to the added web service.
4. Create a new instance of the web service.
5. Use the created instance of the web service to call, ‘ExecuteRequest’.
6. Use the ‘ExecuteRequest’ as a method and pass in the Request XML as a parameter.
Sample .NET code for sending a request to Inteport:
using Name.Inteport;1
{
...
}
1 – Name is the name of the project the client has created
2 – lblURL.Text is a string value containg the Inteport URL
14
Handling an XML Response Every response that is returned is a collection of standard XML tags within an XML document. Just like the request XML which was discussed earlier.
A response translation schema is used to define the structure of the response.
There are two important changes which happen when a request XML when is returned as a response:
1. A ‘result’ element is appended at the end of the list of elements in the application container.
2. What was called the ‘service’ container is renamed to ‘response’. Also the ‘request’ and ‘application_details’ containers are removed and some additional elements added to the ‘response’ container.
These changes occur only if no error was encounter. Otherwise only a response container is returned with several elements used for the error id and description.
Figure 10 – Sample List of Web Services
Retrieving a response of any kind, whether it is an application result or error, is a simple task. The work for accomplishing this was performed when setting up an instance of Inteport and sending a request.
We called an ExecuteRequest method which actually returns an XML response. This can quite easily be captured using a string variable. That string variable can then be loaded in an XML document.
Sample .NET code for receiving a response from Inteport:
XmlDocument xmlTemplateDoc = new XmlDocument();
{
...
}
15
Response Pushback In addition to your Application Submission Request sending you a response, illion Decisioning can also be set up to send a response back to a 3rd party web service if required.
The simplest way for this to work, is to have web service on your system that can accept an XML document of the response that is generated from illion Decisioning, or simply accept a string representation of the XML response (like the ExecuteRequest service does below).
Due to security restrictions and other issues, accepting a web service connection on an external site may not be possible. In such a scenario, the external site may poll illion Decisioning, waiting for a response to a submitted application (for example waiting for an application to reach a final decision after being referred).
To do this, we recommend performing an application search, and then an XML retrieval of the submitted application’s response data.
The following is an example of a search request for the application ‘DE1-8CBAC0F89C10C46-10’.
Search Request XML
<inteflow> <request cd_type=”search”> <user> <id_oper>INTEGATE</id_oper> <tx_password>password</tx_password> </user> <cd_service>SEARCH</cd_service> <cd_security>IFE</cd_security> <id_channel/> <id_company>GENERIC</id_company> <id_merchant>GENERIC</id_merchant> <cd_product>IFE</cd_product> <cd_country>61</cd_country> </request> <service> <search> <cd_typ_srch/> <cd_result_cap>1</cd_result_cap> <id_reference_internal>DE1-8CBAC0F89C10C46-10</id_reference_internal> <id_reference_external/> <nm_surname/> <nm_firstname/> <result/> <credit_product/> <operator/> <id_underwriter/> <channel/> <nm_dealer/> <cd_entity/> <cd_applicant_indiv/> <cd_applicant_comp/>
16
Search Response XML
<inteflow> <response> <database>primary</database> <status>OK</status> <message>Search Successful</message> <matches> <id_application id=”DE1-8CBAC0F89C10C46-10”> <no_sequence>2</no_sequence> <id_flow>SME</id_flow> <id_product_credit id=”COMMERCIAL DECISIONING”>Commercial Decisioning</id_product_credit> <dt_request>2009-05-26 11:53:05</dt_request> <id_merchant_submit>GENERIC</id_merchant_submit> <id_operator_submit>SUPERVISOR</id_operator_submit> <id_merchant_contact>GENERIC</id_merchant_contact> <id_operator_contact>SUPERVISOR</id_operator_contact> <tx_name>COMPANY NAME PTY LTD</tx_name> <tx_othername/> <tx_display>COMPANY NAME PTY LTD</tx_display> <cd_status>Approved</cd_status> <cd_status_processing>Queued</cd_status_processing> <id_queue/> <dt_queue>26/05/2009 11:53:05 AM</dt_queue> <id_channel>INTEGATE</id_channel> <cd_country>61</cd_country> <cd_product>IFE</cd_product> <id_underwriter/> <no_lock>0</no_lock> <id_reference_external/> <ct_note>0</ct_note>
17
<dt_submit>2009-05-26 11:52:11</dt_submit> </id_application> </matches> </response> </inteflow>
Based on whether or not the ‘id_queue’ tag in the search response has a value you can determine if the application has reached a final decision or not. If there is no queue id, then the application has finished all of its processing.
Once you have determined that the application is in a state where you want to receive the current result, you will need to send in a retrieval request to get out all the application details and decisions.
Application Retrieval Where you know the Application ID, you are able to make a call to retrieve the application XML. The following is an example of a retrieval request for the application ‘DE1-8CBAC0F89C10C46-10’.
Application Retrieval Request XML
<inteflow> <request cd_type=”retrieve”> <user> <id_oper>INTEGATE</id_oper> <tx_password>password</tx_password> </user> <cd_service>RETRIEVE</cd_service> <cd_security>IFE</cd_security> <id_channel/> <id_company>GENERIC</id_company> <id_merchant>GENERIC</id_merchant> <cd_product>IFE</cd_product> <cd_country/> </request> <application_details> <id_flow/> <id_reference_internal>DE1-8CBAC0F89C10C46-10</id_reference_internal> <no_sequence>-1</no_sequence> <id_merchant_submit>GENERIC</id_merchant_submit> <id_merchant_contact>GENERIC</id_merchant_contact> <id_operator_submit>INTEGATE</id_operator_submit> <id_operator_contact>INTEGATE</id_operator_contact> </application_details> <service> <retrieve> <flags> <fg_leave_request>0</fg_leave_request> </flags> </retrieve> </service> </inteflow>
18
Note: The flag to keep request details (fg_leave_request) is optional. However, if specified and set to “1” will additionally return the data from the “request” and “application_details” elements from the initial request.
This request example will send you back the current result for the application ‘DE1- 8CBAC0F89C10C46-10’, including all the bureau report responses.
Application Retrieval Response XML
<inteflow> <response> <database>primary</database> <id_reference_internal>DE1-8CBAC0F89C10C46-10</id_reference_internal> <no_sequence>2</no_sequence> <id_channel>INTEGATE</id_channel> <status>Ok</status> <application dt_submit=”2009-05-26 11:52:11.130”> <finance> <cd_type_finance>TERMS 30</cd_type_finance> <am_finance>10000</am_finance> </finance> <applicant fg_new=”0” cd_type=”Principal”> <company> <cd_type_entity>P/L</cd_type_entity> <tx_company_abn>11111111111</tx_company_abn> <tx_company_acn>111111111</tx_company_acn> <nm_company_legal>COMPANY NAME PTY LTD</nm_company_legal> <cd_type_industry>OTHER</cd_type_industry> <no_directors>0</no_directors> <no_employees>0</no_employees> </company> <result> <bureau_list> <bureau id=”ASIC_Refresh_Date”> <id_bureau>DNB</id_bureau> <nm_product>ExtractDateReport</nm_product> <id_service/> <dt_enquiry>26/05/2009 11:52:11 AM</dt_enquiry> <nm_schema_display>DNB Direct ASIC Extract Date Display.xslt</nm_schema_display> <tx_data_bureau> <Response> <ExtractDateReport> <Version>1.1</Version> <Messages ErrorCount=”2”> <Error> <Num>S147</Num> <Desc>Search returned no matches for ACN: 111111111</Desc> </Error> <Error> <Num>S132</Num>
19
<Desc>DUNS resolution failed. Please contact your System Administrator (WebService)</Desc> </Error> </Messages> <Header> <ProductName>ExtractDateReport</ProductName> </Header> <Product/> </ExtractDateReport> </Response> </tx_data_bureau> </bureau> <alert_list> <alert id=”DNBACNError” tx_description=”Error in DNB Bureau ACN Data”/> </alert_list> </result> </applicant> <cd_search_type>O</cd_search_type> <operator> <id_company>GENERIC</id_company> <id_merchant>GENERIC</id_merchant> <id_operator>SUPERVISOR</id_operator> <nm_operator>Supervisor Template</nm_operator> <details> <tx_address/> <tx_area_phone/> <tx_number_phone/> <tx_area_fax/> <tx_number_fax/> <tx_address_email/> </details> </operator> <result> <cd_status_processing submitdate=”2009-05-26” submittime=”11:52:11.130” latestdate=”2009-05-26” latesttime=”11:52:11.130” date=”2009-05-26” time=”11:53:05” user=”SYSTEM”>Queued</cd_status_processing> <cd_status_current date=”2009-05-26” time=”11:53:05” user=”SUPERVISOR” tx_description=”Appliation Approved”>Approved</cd_status_current> <cd_status_historical date=”2009-05-26” time=”11:52:13” user=”SYSTEM”>Assess</cd_status_historical> <print_list> <print id=”Print Option 1” tx_display=”Print Assessment” cd_output=”PDF” tx_image=”” tx_schema=”xslSME_PrintApplication.xsl” fg_printed=”0” fg_show=”1” id_level=”Application”> <parameter_list> <parameter name=””/> </parameter_list> <privilege_list> <privilege>CREDIT</privilege> <privilege>ADMIN</privilege> <privilege>OPERATOR</privilege> <privilege>SUPERVISOR</privilege>
20
</privilege_list> </print> </print_list> <cd_status_historical date=”2009-05-26” time=”11:52:13” user=”SYSTEM”>Refer</cd_status_historical> <tx_message_application/> <action_list> <action id_object=”” id_action=”Override: Withdraw Application” id_queue=””> <privilege_list> <privilege id=”ADMIN”/> <privilege id=”SUPERVISOR”/> </privilege_list> </action> <action id_object=”” id_action=”Override: Decline Application” id_queue=””> <privilege_list> <privilege id=”ADMIN”/> <privilege id=”SUPERVISOR”/> </privilege_list> </action> </action_list> </result> <application_notes/> </application> </response> </inteflow>
21
Document Management illion Decisioning allows users to attach documents to applications through a simple standard SOAP request.
This enables users to upload documents to the desired application, making it easily accessible and application specific.
Uploaded documents will be encoded and stored to the database to the following two tables:
- t_req_upload: Contains the document name, ID and size.
- t_req_upload_data: Contains the ID and the encrypted document.
Upload Document Request The upload request requires log in credentials, the associated application ID, attachment type, document name, and document contents encoded in a base 64 string.
Users will be required to send their requests to the following URL: http://[InteportURL]/inteport/decisiongateway.asmx?op=UploadAndAttachD ocument
Request Description
Name Element Comment
Company Name _sCompany Identifies the name of the company you are submitting your request to.
Merchant Id _sMerchant The ID of the merchant to contact. The merchant you are submitting the application under.
Operator Id sOperator The ID of the merchant doing the submitting.
Password _sPassword The password of the operator submitting the application.
Application ID _RequestID The application ID you are uploading the document to.
Attachment Type __AttachmentType Identifies the category/group you are uploading the documents to.
File Name _Filename The name of the file you are uploading The file type must be included e.g. Doument1.doc
Document Content _Document The content of the document you are uploading. It must be encoded to a Base 64 String.
22
The following is a request example of attaching a document to application ‘DE1-8CBAC0F89C10C46- 10’.
<soap:Envelope xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns:xsd=”http://www.w3.org/2001/XMLSchema” xmlns:soap=”http://schemas.xmlsoap.org/soap/envelope/”> <soap:Body> <UploadAndAttachDocument xmlns=”http://decisionintellect.com/inteport/”> <_sCompany>COMPANY</_sCompany> <_sMerchant>MECHANT</_sMerchant> <_sOperator>INTEGATE</_sOperator> <_sPassword>password</_sPassword> <_RequestID> DE1-8CBAC0F89C10C46-10</_RequestID> <_AttachmentType>FinanceDocuments</_AttachmentType> <_Filename>test.txt</_Filename> <_Document> VGhpcyBpcyBhIHRlc3QgZmlsZS4=</_Document> </UploadAndAttachDocument> </soap:Body> </soap:Envelope>
Upload Document Response Once an upload request is sent, a response containing the result of your request is returned.
The response will contain the status of your response and the application ID.
The following is a response example after attaching a document to application ‘DE1- 8CBAC0F89C10C46-10’.
<soap:Envelope xmlns:soap=”http://schemas.xmlsoap.org/soap/envelope/” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns:xsd=”http://www.w3.org/2001/XMLSchema”> <soap:Body> <UploadAndAttachDocumentResponse xmlns=”http://decisionintellect.com/inteport/”> <UploadAndAttachDocumentResult> <inteflow xmlns=”http://decisionintellect.com/inteport/”> <response> <id_reference_internal>DE1-8CBAC0F89C10C46- 10</id_reference_internal> <status>Ok</status> </response> </inteflow></UploadAndAttachDocumentResult> </UploadAndAttachDocumentResponse> </soap:Body> </soap:Envelope>
23
Appendix A – Sample Request
24
25
Appendix B – Sample Response
26
Appendix C – Service Implementation and WSDL The full WSDL can be located at: https://www.inteflow.com.au/inteport/DecisionGateway.asmx?WSDL
DecisionWebGateway ExecuteRequest [Recommended] Inteflow basic request Used if sending a request in string format.
SOAP 1.1
The following is a sample SOAP 1.1 request and response. The placeholders shown need to be replaced with actual values.
POST /inteport/DecisionGateway.asmx HTTP/1.1 Host: www.inteflow.com.au Content-Type: text/xml; charset=utf-8 Content-Length: length SOAPAction: “http://decisionintellect.com/inteport/ExecuteRequest” <?xml version=”1.0” encoding=”utf-8”?> <soap:Envelope xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns:xsd=”http://www.w3.org/2001/XMLSchema” xmlns:soap=”http://schemas.xmlsoap.org/soap/envelope/”> <soap:Body> <ExecuteRequest xmlns=”http://decisionintellect.com/inteport/”> <_sRequestXML>string</_sRequestXML> </ExecuteRequest> </soap:Body> </soap:Envelope> HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Content-Length: length <?xml version=”1.0” encoding=”utf-8”?> <soap:Envelope xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns:xsd=”http://www.w3.org/2001/XMLSchema” xmlns:soap=”http://schemas.xmlsoap.org/soap/envelope/”> <soap:Body> <ExecuteRequestResponse xmlns=”http://decisionintellect.com/inteport/”> <ExecuteRequestResult>string</ExecuteRequestResult> </ExecuteRequestResponse> </soap:Body> </soap:Envelope>
SOAP 1.2
The following is a sample SOAP 1.2 request and response. The placeholders shown need to be replaced with actual values.
POST /inteport/DecisionGateway.asmx HTTP/1.1 Host: www.inteflow.com.au Content-Type: application/soap+xml; charset=utf-8 Content-Length: length
27
<?xml version=”1.0” encoding=”utf-8”?> <soap12:Envelope xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns:xsd=”http://www.w3.org/2001/XMLSchema” xmlns:soap12=”http://www.w3.org/2003/05/soap-envelope”> <soap12:Body> <ExecuteRequest xmlns=”http://decisionintellect.com/inteport/”> <_sRequestXML>string</_sRequestXML> </ExecuteRequest> </soap12:Body> </soap12:Envelope> HTTP/1.1 200 OK Content-Type: application/soap+xml; charset=utf-8 Content-Length: length <?xml version=”1.0” encoding=”utf-8”?> <soap12:Envelope xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns:xsd=”http://www.w3.org/2001/XMLSchema” xmlns:soap12=”http://www.w3.org/2003/05/soap-envelope”> <soap12:Body> <ExecuteRequestResponse xmlns=”http://decisionintellect.com/inteport/”> <ExecuteRequestResult>string</ExecuteRequestResult> </ExecuteRequestResponse> </soap12:Body> </soap12:Envelope>
28
Version Date Name Description
1.1 March 2018 Saleem Azad Transferred document to illion template
1.2 April 2018 Kristin Witt Updated technical diagram
1.3 Sep 2018 Fiona Maher Changed name of document from Connectivity Guide to Web Service Submission Guide.
1.4 Nov 2018 Rory Dwyer Removed obsolete rows from example XML
1.5 March 2019 Fiona Maher Updated Inteflow to illion Decisioning where applicable.
1.6 October 2020 Ben Sawyer Updated “retrieve” documentation to include information about flags.
illion Decisioning
Getting Started
Engine
Building an XML Request
Submit Application
Resubmit Application
Action Application
Request Elements
* Although the schema does not require the element, every effort to include all details should be made
Application Details
Figure 10 – Sample List of Web Services
Handling an XML Response
Appendix D – Document History