developers.valex.com.au - Valex Developer Documentation

We've updated our test site to the next version of ValEx code. Please let us know if you encounter any issues.

In an upcoming release around February 2010, we will be sending Funder Specific Information in our LIXI packets under /ValuationTransaction/RelatedPartySegment/RelatedParty[@RelPartyType='Lender']/@RelPartyDescription

ValEx supports a number of WorkFlow events, but doesn't have a way to map "Attempting Contact" and "Appointment Cancelled".

We're looking for input on the best way to implement such functionality between us and our valuation firms.

Our suggestions are:

• Attempting Contact: After the initial 'instructed' / 'assigned' packets, sending one of these would represent 'attempting contact' and provide notes as appropriate.
• Appointment Cancelled: Sending an appointment workflow, and then an InProgress (without a new appointment date) would cancel an appointment

A lot of our lixi valuation firm partners in regional areas often come across the situation where they have to use out of date sales evidence to support their report.

This means the report is likely to need review by out compliance department. Previously, we've automatically generated the compliance note from the valuer in these cases.

Going forward, we'll be looking at //CompletionDetails/LendersCaution and //CompletionDetails/LendersCautionComment to populate this information.

At this time, we will not be rendering this to our LIXI clients and lenders.

ValEx will support this some time around January 2010 15th February 2010.

We've deployed the Large File Attachment implementation to our test and production servers.

Discussions on the lixi mailing lists about this has brought us:

The full URI for the attachment should be placed into the SourceDomain
attribute of the Attachment element. The user guide comment for Source
Domain in the current schema is as follows "The SourceDomain is intended to
be a URI that identifies where the attached file might be accessed from, or
just an identifier of the owner of the document. While it is anticipated
that it will generally be a URI scheme starting with "http://" or "ftp://",
there is no requirement for this to be the case."

If there is a separate filename then that would be placed into the Filename
attribute, and this would obviate the need for a "Type" attribute. In the
example that Daniel has provided below, the URI does not list the name of
the file, rather how one retrieves it. So the XML would look like:

<Attachment SourceDomain="http://vx.valex.com.au/documents/view.php?id=1"
FileName="1234.jpg" />

We'll be both parsing and rendering attachments in this way, on an opt-in basis.

If you would be interesting in trialling this, please contact us.

We have implemented an update() Web Service.

The update() Web Service is roughly equivalent to the functionality available via the Job Edit tab. LIXI parties (Clients and Valuation Firms) will be able to amend details such as:

• Job address
• Job contacts
• New Documents
• Purchase Price / Contract Price information

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.