XML Integration Updates

Most recent XML Documentation here


March 20, 2017

New PROBLEM_TYPE and PROBLEM_CODE fields - (April 11, 2017)

PROBLEM_TYPE and PROBLEM_CODE fields are going to be added into our XML messages structure to make the problem description more detailed. XML schema is going to be updated - please be prepared.
If you want to test incoming / outgoing XML with these fields, you can do this on ST1 environment. Contact ServiceChannel support if you need any assistance.

XML Specification Updated

Our XML specification was updated to reflect upcoming changes in XML data format. You can download v.4.6 here.

XML Updates - Error Statistics

It is important to ensure there are no major issues with your XML integration. As such, we now calculate error statistics by type for each integrated service provider. If you are interested in receiving this information, please send an email to contractorsupport@servicechannel.com with “XML Errors Stats” in the subject line and we will add you to future communications.


November 30, 2016

New EXPIRATION_DATETIME Field

EXPIRATION_DATETIME field was added into our XML messages structure. This date and time value (reflected in local time zone) should allow better handling of Preventative Maintenance work orders.

Error Message Update

We’ve updated messages that the XML integration generates in the event an error occurs through an incoming messages.


October 20, 2016

IP Changes for SB2 and ST1 Environments

IMPORTANT: We have updated the IPs for our SB2 and ST1 environments which are used for XML integration testing. The new IP addresses are:

  • 54.208.11.163
  • 54.208.42.100
  • 107.23.17.74
  • 54.236.157.20

In the event you are using a firewall, please be sure to add these IP addresses to your whitelist.


September 28, 2016

New XML Permission Added

A new XML permission is now available for the COMPLETED / PENDING CONFIRMATION status. If your client(s) decide to disable this permission, you are required to re-sign the SC Client Integration Request Form.


August 14, 2016

Auto-Generated Notes for SCHED_DATETIME

A previous update to the record SCHED_DATETIME occurred via XML integration without a note. As a result this meant that updates were invisible to clients and we received complaints that they could not see who made the change and when. To address this, we now create an auto-generated notes for this record.

The following example demonstrates what is generated each time you send us an XML message with SCHED_DATETIME field, without adding a note:


July 5, 2016

XML Integration specification v.4.4 released

An updated version of XML Integration specification was released. Please see the updated documentation here.

Most important changes:

1. LINE field in notes is now deprecated. it’s still included into outgoing XML messages for compatibility reasons, but the value can be incorrect. Please use DATETIME field to sort notes.

2. MAIL_TO field added for incoming notes (works with ACTION_REQUIRED flag). Now you can explicitly list recipients for an e-mail to be generated by your note.

Sample:

<?xml version="1.0"?>
<DATA2SC PIN="40487" ID="127">
<CALL TR_NUM="54889692">
<ATTR NAME="NOTE" ACTION_REQUIRED="1" MAIL_TO="user@company.com;anotheruser@company.net">Note from XML with emails</ATTR>
</CALL>
</DATA2SC>

By default this feature is disabled, if you want to enable it for some specific client, please send a message to contractorsupport@servicechannel.com.

CALL DATETIME vs SCHED_DATETIME

Always keep your eyes on work order Call Date while setting Scheduled time - SCHED_DATETIME can't be set before Call Date. This is mostly about auto generated PM (Maintenance) work orders which are usually created in advance with Call Date in future.

We've enforced validation for create / update requests in incoming XML, so any XML message violating this rule will be rejected with "Scheduled date/time is less than call date/time" error. 


February 22, 2016

XML Integration specification v.4.3 released

An updated version of XML Integration specification was released. We are doing our best to keep this documentation full, clean and up-to-date.

Please see the updated documentation here.

Support for all ServiceChannel statuses in XML

In a February, 2016 support for all statuses used in SC (including subscriber‐specific) was implemented in XML integration. For compatibility reasons the same STATUS field is used, but the value in this field can be complex.

The following procedure is used on SC side for incoming XML:
‐ take the value of STATUS field if any was provided
‐ try to perform mapping procedure according to the table in the section above
‐ if STATUS was not recognized as XML‐specific and no mapping performed, parse STATUS value as it's combined like <PrimaryStatus>+<ExtendedStatus> (plus sign delimited)

For outgoing XML:
‐ take WO status (Primary & Extended parts)
‐ try to perform mapping procedure
‐ if this status can not be mapped into XML‐specific, create a value as

<PrimaryStatus>+<ExtendedStatus> (plus sign delimited)
‐ send the value in STATUS field

Examples:
‐ Status IN PROGRESS / PARTS ON ORDER will be always sent out from SC as
STATUS=“PARTS_ON_ORDER”
‐ Status IN PROGRESS / MATERIALS SHIPPED will be always sent out from SC as STATUS=“IN
PROGRESS+MATERIALS SHIPPED”
‐ Status IN PROGRESS / PARTS ON ORDER can be sent to SC as STATUS=“PARTS_ON_ORDER” or
STATUS=“IN PROGRESS+PARTS ON ORDER”

This way XML integration is handling all SC statuses without losing compatibility with old implementations.


January 19, 2016

HTTP 'POST' vs. 'GET'  

Our XML integration supports pushing data over both HTTP POST and GET.

Note: Sometimes work orders are created from proposals and the problem description in this case can be very long, exceeding GET limitations. This can result in errors on message transfer & processing.

If you are still using GET please consider the option to switch to POST.

Completed Statuses

We have several providers that are using XML integration to set work orders into "Completed" or "Completed / Confirmed" statuses. These statuses are actually counted as "final" and in most cases should only be used by subscribers. Except in some really special cases, providers should use "Completed / Pending Confirmation."

Please review your implementation and check if you absolutely need to use "Completed" or "Completed / Confirmed" statuses.

ServiceChannel is reviewing an option to add appropriate restrictions to XML integration.