Update: FINAL OUTBOUND FORMATS

Follow

Comments

6 comments

  • 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.
  • 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">)

  • 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>

     

     

  • Sher Kirk

    Hi Anthony,

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

    Sher

  • 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.

  • 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.

Please sign in to leave a comment.