developers.valex.com.au - Valex Developer Documentation

Some things just don't fit into LIXI. ValEx also produces a multitude more emails and other notifications that it does via webservices.

A quick and easy way to route / attach communications from ValEx to your system may be to look at our mail headings.

Typical emails produced by ValEx render information like:

X-ValEx-JobID: 1244566
X-ValEx-ValfirmID: 119
X-ValEx-ValuerID: 1009
X-ValEx-Valuer: Office Valuer
X-ValEx-Valfirm: Example Valfirm
X-ValEx-UserID: 50348
X-ValEx-ClientID: 1234
X-ValEx-ServiceID: 23
X-ValEx-Service: Const. Short Form
X-ValEx-FunderID: 0
X-ValEx-Funder: 
X-ValEx-Realm: valfirm

We've found this helpful for routing the massive amounts of email from inbox to inbox, as well as embedding relevant metadata.

If you are interested in this kind of thing, let us know.

Clients can indicate to us that a loan may incur mortgage insurance with the below xpath:

//RealEstate[@MortgageInsurance="Yes"]

This can also be set by the valuation firm.

We'll be introducing a new variant of a ShortForm report, a Retrospective valuation.

These valuations are done as a comparison to an original report, and use sales evidence from the period of original valuation.

For MIP (Mortgagee In Possession reports), we'll sometimes require a Forced Sale Value - what the subject property would fetch.

Of course, then there's the combination of a MIP Retrospective valuation - we aren't currently explictly modelling this, however may do so in the future.

Retrospective valuation requires a valuation date which is the date of original inspection and will be the 'valuation assessment' basis.

Check out the service type mappings.

Service type: XPaths

We'll parse and render a both of:

//FullRegistered[@ValSubType=ShortForm]
//FullRegistered/SubTypeNote/text() == "Retrospective Short Form"

To indicate we are ordering a Retrospective Short Form.

We'll parse and render both of:

//FullRegistered[@ValSubType=Standard]
//FullRegistered/SubTypeNote/text() == "Retrospective Long Form"

To indicate we are ordering a Retrospective Long Form.

Forced Sale Value: XPaths

ValEx will look for a Forced Sale Value in both of:

//ValueComponent[@OtherValue]
//ValueComponent[@OtherValueDescription="Forced Sale Value Range"]

Formatted as a xsd:decimal.

Valuation Date: XPaths

ValEx will model valuation date as an inspection appointment.

//FullRegistered/InspectionAppointment[0] # Normal inspection information
//FullRegistered/InspectionAppointment[1] # Retrospective valuation date

We have roughly documented our job state transitions as a UML State Diagram.

Disclaimer: It may not be accurate to the finest detail but it should suffice. Feedback is welcome.

Please find the PDF attached.

One common implementation problem we're running into is inline attachments for lixi packets.

The schema defines an element to base64 encode binary files. Typically, this runs from 1-6mb in packet size for a completed valuation report (PDFs, titles, invoices, etc).

<xs:element name="InlineAttachment" type="xs:base64Binary">

What tends to happen is someone deploys a system, and a few days later, packets are being rejected as they are beyond the capabilities of the server's default configuration.

We'd like to get opinions on how others have solved this, and also propose an idea or two.

The suggestion:
So, a lot of valuation systems are using SOAP and are doing so from web based systems.

Common tools for linux environments include things like 'wget' and there are an abundance of simple HTTP client libraries in a variety of languages.

HTTP also provides a mechanism to do authentication (HTTP Basic Authentication), as well as compression ("Accept-Encoding").

I'd like to suggest:

  <xs:element name="Attachment">
    <xs:complextype>
      <xs:sequence>
        <xs:element minoccurs="1" ref="Identifier">
        <xs:element minoccurs="1" ref="RelatedEntityRef">
        <xs:element minoccurs="1" ref="InlineAttachment">
      </xs:element>
      <xs:attribute name="SourceDomain" type="xs:string">
      <xs:attribute name="Filename" type="xs:string">
    </xs:attribute>
  </xs:attribute>

1. Loses the minOccurs=1 restriction on InlineAttachment
2. Either the Identifier element or a specific new element is used to capture a URL
   

   <Identifier uniqueid="http://vx.valex.com.au/documents/view.php?id=1">

   or

   <File href="https://vx.valex.com.au/documents/view.php?id=1" type="image/jpeg">

3. Implementors determine an authentication mechanism between the systems, based on HTTPS and HTTP Basic Authentication

   A simple client would:

   1. Match the domain against an internal list of usernames/passwords to use
   2. Send a HTTP GET, and provide the username/password
   3. If needed, the simple client specify it can accept gzip/other compression encoding to the server (just like your browser does)
   4. If needed, the simple client respect last-modified-times / e-tags (also like your browser)

So:
What do people think of such a thing?
How have others been dealing with this situation?

Opening a Query

We provide a requestValuationQuery() method for clients.

Within ValEx only allow one open query at a time - subsequent queries are appended as notes.

We would like to encourage our valuation firm users to implement a similar method in their soap services.

This will allow valuation firms to accept valuation queries in a meaningful way.

Resolving a Query

We provide a submitValuationQueryResponse(string xml, string resolution, string comment) method for indicating a resolution to a query.

We'd like all of our clients (to provide such a method in their soap service) and valuation firms (to send us responses) to consider implementing this.

The current resolutions within ValEx are:

• agree

  Will amend report

• disagree

  Query closed

Amending a report with no Open Query

We also allow valuation firms to send an amended report in some circumstances. This is documented here.

Rasika asks:
What's the XPath for 'Title Details > Further Details' is please?

We parse Torrens Title information from the //Title element.

We don't currently map all elements and attributes here, only @TorrensVolume, @TorrensLot, @TorrensFolio, @TorrensPlan, and @OtherTitleDescription.

We also parse all //RegisteredProprietor/PersonName/FullName nodes into a string seperated list of names.

Finally, we parse all //Encumberance/Comment into a string description of restrictions for the subject property.

Unfortunately we don't capture this information as it is not well modelled in LIXI.

We'll be investing some time in improving these questions and how they are mapped in LIXI in the near future (Late 2009), however for the moment your users will have to populate this information in ValEx's user interface.

Please note, the below documentation was written in 2009! Please contact it@corelogic.com.au for documentation/support on sending responses to the ValEx system for Kerbsides

---

We use the lixi RestrictedAccessAssessment option for Kerbside jobs.

This will mean that Kerbside jobs will come to you in a RestrictedAccessAssessment node instead of a FullRegistered node.

Apart from the name, little is different about the requests other than //RestrictedAccessAssessment[@ResultRequired='SinglePoint'] could be used to signify if a client wants a mid point to go along with the range.

We would also parse these nodes back from the valfirm in the response packet.

When an external inspection is not appropriate you would fill in the
//Disclaimer node, otherwise leave it completely blank.

Attached to this article is a sample request and response document and a csv with the xpaths we're currently considering using for this.

See also:
Service type mappings

Errors

If the client configuration is different to the LIXI packet we receive, you may encounter an error like:

XYZ will not accept a Kerbside Assessment where an indication is made that an External Inspection is NOT appropriate and therefore no market value is provided. Please contact Valuation Exchange to arrange an Escalation of the Service Type.

We'll be updating our test site on Sun 31st May 2009.

This will enable implementors to test our Expected Selling Period, Workflow and our updated LIXI XSD (1.3.7).

If you have any questions, let us know.