Articles in this section

See more

Update: FINAL OUTBOUND FORMATS

Sher Kirk
  • Updated
Follow

We understand that there have been several small changes and inconsistencies between the xml, flat format and the structure guide for outbound tickets and that is has been causing delays in testing. For that we apologize.
Last night, the development team went through, line by line, and resolved any remaining inconsistencies between formats and outputs.
NOTE: There is an inconsistency with the 'seconds' output between the xml and readable text format (showing zeroes) that will be resolved on Monday, Oct. 22)
NOTE: It is possible that there may be one additional field added to the output before launch
(Original Ticket Number). This is dependent on the solution for Corrections, and whether they can keep the same ticket number. Not yet resolved.

Attached below are
WC Data Structure Guide: an Excel document that defines each line of output for both the text (readable) format and the xml format.

Readable Text body email: Sample of the readable text that will be in the body of the email. (NOTE: This text should appear in the body of all outbound ticket emails after Monday, Oct. 22)

onecall.xsd: The schema for programming xml tickets into parsing systems. NOTE: Once we are in production environment, this file will be accessed for each ticket from a link within the xml file itself. (-<onecall:OneCallReferral xsi:schemaLocation="https://www.pelicancorp.com/onecall/bydp.xsd" xmlns:onecall="http://www.pelicancorp.com/onecall" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xlink="http://www.w3.org/1999/xlink">)
This file is provided for system configuration, but ticket management systems should resolve the xml schema directly from the link once we are live, therefore ensuring that the most current schema is always available.

20184200087.xml: Sample of an xml ticket output

20184200087.gif: Sample image file that will be attached to all outbound tickets - screenshot of the dig site polygon drawn by the User.

20184200087.gml: Sample gml file that will be attached to all outbound tickets. This is a geo-data file containing the actual polygon drawn by the User. It is meant to be pulled into mapping software to lay the polygon over member facility maps for comparison/screening purposes. This file is spatially accurate, based on your map projection information. Members using the gml file will have to provide BYPD with preferred projection.

20184200087.pdf: Sample of PDF attachment to be sent with all outbound ticket formats.
NOTE: the statement/advisory sections of the PDF are not final, but the ticket output fields are.

Related articles

Comments

6 comments

Date Votes
  • Anthony See

    I have concerns regarding the requirement for the XSD to be accessed directly from PelicanCorp for each ticket being processed from AlbertaOneCall:

    The reasons for these are as follows:

    • If changes are made to the schema in PRODUCTION, how would we know what was changed, why it was changed and who changed it
    • There should be a defined software development life cycle (DEVELOPMENT -> TEST -> PRODUCTION). If new fields are going to be introduced into the schema, it should be included in the TEST environment so that downstream systems that operate on those tickets could can test to ensure that changes not will break their systems without any manual user intervention. Only once they are successfully tested in the TEST environment should these changes then be promoted to PRODUCTION.
    • Any breaks in the processes in PRODUCTION will cause unnecessary time to manually fix all the tickets introduced by the unexpected changes.
    • Performance reasons
      • If we have to download the schema for each and every ticket, there could potentially be a slow down on processing the tickets.
        • One call to retrieve the ticket.
        • And another call to retrieve the schema. (This instead should be cached on the downstream servers for efficiency reasons.)
      • Unavailable schema due to a reliance on PelicanCorp’s servers:
        • What if Pelican’s servers become unavailable and downstream systems are unable to retrieve the schema? This could cause our system processes to fail because we cannot validate the incoming tickets according to the schema.
    0
    Comment actions Permalink
  • Anthony See

    Other concerns:

    • If changes are expected, then the schema should be versioned so that downstream systems can easily identify if a change has occurred. For example (in bold):

    (<onecall:OneCallReferral xsi:schemaLocation="https://www.pelicancorp.com/onecall/bydp.xsd" xmlns:onecall="http://www.pelicancorp.com/onecall/2018/10/22" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xlink="http://www.w3.org/1999/xlink">)

    0
    Comment actions Permalink
  • Anthony See

    I have tried to import the XSD schema into my process but I get an error with the following details:

    Failed to load schema.

    Reason : 
    The 'http://www.w3.org/2001/XMLSchema:element' element is not supported in this context.

    I took a look at the schema and noticed where the issue is:

    There should be either a choice or a sequence element on line 10. I would prefer it to be a sequence as then all the elements need to be in the correct sequence which would make validating the data to the schema easier.

    I have posted my version of the schema here in case you want to take a look at it:

    <?xml version="1.0" encoding="utf-16"?>
    <xs:schema xmlns:xlink="http://www.w3.org/1999/xlink"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
     attributeFormDefault="unqualified" 
     elementFormDefault="qualified" 
     targetNamespace="http://www.pelicancorp.com/onecall" 
     xmlns:xs="http://www.w3.org/2001/XMLSchema">
     <xs:element name="OneCallReferral">
     <xs:complexType>
     <xs:sequence>
     <xs:element name="ReferralDetails">
     <xs:complexType>
     <xs:sequence>
     <xs:element name="MessageVersionNumber" type="xs:string" />
     <xs:element name="From" type="xs:string" />
     <xs:element name="RequestMedium" type="xs:string" />
     <xs:element name="UtilityID" type="xs:integer" />
     <xs:element name="StationCode" type="xs:string" />
     <xs:element name="UtilityName" type="xs:string" />
     <xs:element name="To" nillable="true" type="xs:string" />
     <xs:element name="JobNumber" type="xs:integer" />
     <xs:element name="TicketNumber" type="xs:string" />
     <xs:element name="PreviousTicketNumber" nillable="true" type="xs:string" />
     <xs:element name="SequenceNumber" type="xs:integer" />
     <xs:element name="RequestDateTime" type="xs:dateTime" />
     <xs:element name="WorkToBeginDate" type="xs:dateTime" />
     <xs:element name="WorkCompletionDate" nillable="true" type="xs:date" />
     <xs:element name="IsEmergency" type="xs:boolean" />
     <xs:element name="TicketStatus" type="xs:string" />
     <xs:element name="TicketType" type="xs:string" />
     <xs:element name="WorkType" type="xs:string" />
     <xs:element name="Activity" type="xs:string" />
     <xs:element name="ExcavationMethod" type="xs:string" />
     <xs:element name="ExcavationDepth" type="xs:string" />
     <xs:element name="ExcavationSize" type="xs:string" />
     <xs:element name="AreaMarked" type="xs:boolean" />
     <xs:element name="UserReference" nillable="true" type="xs:string" />
     <xs:element name="WorkingOnBehalfOf" type="xs:string" />
     <xs:element name="WorkingForAuthority" type="xs:string" />
     <xs:element name="StationList">
     <xs:complexType>
     <xs:sequence>
     <xs:element minOccurs="0" maxOccurs="unbounded" name="StationCode" type="xs:string" />
     </xs:sequence>
     </xs:complexType>
     </xs:element>
     </xs:sequence>
     </xs:complexType>
     </xs:element>
     <xs:element name="CustomerDetails">
     <xs:complexType>
     <xs:sequence>
     <xs:element name="ID" type="xs:integer" />
     <xs:element name="Name" type="xs:string" />
     <xs:element name="Company" nillable="true" type="xs:string" />
     <xs:element name="UserType" nillable="true" type="xs:string" />
     <xs:element name="Phone" type="xs:string" />
     <xs:element name="Mobile" nillable="true" type="xs:string" />
     <xs:element name="EmailAddress" nillable="true" type="xs:string" />
     <xs:element name="OnsiteContactName" nillable="true" type="xs:string" />
     <xs:element name="OnsiteContactPhone" nillable="true" type="xs:string" />
     </xs:sequence>
     </xs:complexType>
     </xs:element>
     <xs:element name="LocationDetails">
     <xs:complexType>
     <xs:sequence>
     <xs:element name="Address" nillable="true" type="xs:string" />
     <xs:element name="CityTown" nillable="true" type="xs:string" />
     <xs:element name="ProvinceTerritory" type="xs:string" />
     <xs:element name="NearestCrossStreet" nillable="true" type="xs:string" />
     <xs:element name="PropertyType" nillable="true" type="xs:string" />
     <xs:element name="PropertyDetail" type="xs:string" />
     <xs:element name="UrbanRural" type="xs:string" />
     <xs:element name="MunicipalDistrict" nillable="true" type="xs:string" />
     <xs:element name="NearestCommunity" nillable="true" type="xs:string" />
     <xs:element name="RuralSubdivision" nillable="true" type="xs:string" />
     <xs:element name="LotNo" nillable="true" type="xs:string" />
     <xs:element name="BlockNo" nillable="true" type="xs:string" />
     <xs:element name="PlanNo" nillable="true" type="xs:string" />
     <xs:element name="LandGridType" nillable="true" type="xs:string" />
     <xs:element name="LandGrids" nillable="true" type="xs:string" />
     <xs:element name="Latitude" nillable="true" type="xs:decimal" />
     <xs:element name="Longitude" nillable="true" type="xs:decimal" />
     <xs:element name="Remarks" nillable="true" type="xs:string" />
     </xs:sequence>
     </xs:complexType>
     </xs:element>
     </xs:sequence>
     </xs:complexType>
     </xs:element>
    </xs:schema>

     

     

    0
    Comment actions Permalink
  • Sher Kirk

    Hi Anthony,

    We passed along the information to the Pelican Dev Team and are waiting for a response back for you.

    Sher

    0
    Comment actions Permalink
  • Sher Kirk

    In regards to changes to the schema:

    They responded that the xml schema update would not break your parsing, as it would ignore new fields until you parse them.

    If there are to be any changes to the schema, we would still be required to give advance notice to our members as to the what and when. I’m sure we can arrange for some testing to be done prior to just updating the schema document.

    0
    Comment actions Permalink
  • Sher Kirk

    In regards to downloading the schema:

    Currently, testers should be using the separate xsd document provided with the xml format samples. The schema will not be loaded into the target server until later in the process.

    In regards to Line 10 - still waiting for a response.

    0
    Comment actions Permalink

Please sign in to leave a comment.