ATTENTION: CHANGE TO TICKET FILE NAME IS REQUIRED

Comments

25 comments

  • Official comment
    Sher Kirk

    Per the mini-update, we have to focus on the validation of the system data right now. Last night, the migration of the data from Pre-production to Production took place. I have a meeting in 20 minutes to discuss the results. If everything went as planned, I will have another update for everyone later today - to be posted in Announcements.

    In the meantime, we have Pelican using the information provided by members to do testing on the persistent Ticket Edit Issue you are reporting. More resources can be put on this problem starting tonight.

    Comment actions Permalink
  • Regan Brown

    Hi Sher,

    Would it be better to add a timestamp (something like YYYYMMDDhhmmss) to the filename instead?  What will happen if two "correction" (or ticket edits) happen on the same ticket number?

    0
    Comment actions Permalink
  • Sher Kirk

    We can consider a timestamp option. Our thinking is that some members might already have scripts/rules associated with having the ticket type in the file name (because they are in some cases in the current systems). We were trying to find the solution that makes the change the easiest to make and to test/configure on the member side.

    If anyone else wants to weigh in, we can still make the decision to go timestamp instead of ticket status appended to the file name.... (?)

    I'm listening and open to suggestions.

    0
    Comment actions Permalink
  • Regan Brown

    I would suggest a timestamp inclusion, something along the lines of TICKETNUMBER_STATIONCODE_TIMESTAMP.xml

    ie. 20190200145_TELSMDHT_20190111163103.xml   ( and .gml / .pdf / .gif the same )

    In the BYDP workflow, I expect it's unlikely that two unique data transmissions would happen for the same ticket, same station code, within the same second... so including a timestamp accurate down to the second should pretty much guarantee there won't be a file over-write issue in an FTP environment.

    0
    Comment actions Permalink
  • Louie, Herman

    We take the ticket number and suffix it with sequence no.  Is it possible to create/add sequence a new number for ticket?

    ie: this way we store the lifecycle of the ticket

    Email View

    2019010025-41199 = Original Ticket
    2019010043-41200 = Original Ticket
    2019010025-41201 = Change Location Ticket
    2019010030-41202 = Original Ticket
    2019010025-41203 = Change Location Ticket
    2019010040-41204 = Original Ticket
    2019010025-41205 = Cancel Ticket

    FTP Directory View

    2019010025-41199 = Original Ticket
    2019010025-41201 = Change Location Ticket
    2019010025-41203 = Change Location Ticket
    2019010025-41205 = Cancel Ticket
    2019010043-41200 = Original Ticket
    2019010030-41202 = Original Ticket
    2019010040-41204 = Original Ticket

    0
    Comment actions Permalink
  • Sher Kirk

    Interesting Herman. I'm afraid my FTP knowledge is fairly limited. Can you explain to me how your system identifies "Change Location" and "Cancel" ? Perhaps it would be easier to adopt this change rather then changing file names at this late stage of the game?

    What about if you receive tickets for multiple station codes in your FTP (then multiple copies of the edit as well?)

    0
    Comment actions Permalink
  • Louie, Herman

    Currently with process ticket the same, Original/Change/Cancel, yes we even process Cancel ticket as if it's original or change with an auto process the ticket.

    The big difference is use email with XML and GML for the are of interest.  Same ticket number could, morning comes and original ticket, the afternoon comes a change ticket and at the end of the day is the cancel ticket. (only store the ticket sent in that day)

    I'll test it this weekend, one ticket as BURNAB01 and BURNAB02

     

     

    0
    Comment actions Permalink
  • Patterson, Julie

    Currently the 'ticket status' reflects type of ticket (on BCH is 'Located', Pending - which reflects if the system was able to find the location based on the .XML info) and there is where we see if the ticket is 'Cancelled' . can we not use the same logic for Pelican?

     

     

    0
    Comment actions Permalink
  • Patterson, Julie

    if not- time stamp makes the most sense.

    0
    Comment actions Permalink
  • Kevin Grice

    For FortisAlberta our current tickets come in named <station code> <ticket number> <datetimestamp> .dbf since the early days of this integration.  Example: FTACOC69201430005120140805144540.dbf.  The date time stamp really helps us determine when a file came in when we have to research any issues.

    0
    Comment actions Permalink
  • Patterson, Julie

    just heard from IT - to add the time stamp will require a re-write of our ticket engine and it is only 2 weeks to go live. Why can you not reflect the Ticket_Status appropriately ?

    0
    Comment actions Permalink
  • Sher Kirk

    The ticket status is showing correctly in the XML we have tested. If you can use that in your system, we don't have to change anything. We just need to figure out why your system is not showing the canceled tickets. Everyone else seems to be receiving them.

    See MBHYDRO sample:

    <?xml version="1.0" encoding="UTF-8"?>

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


    -<onecall:ReferralDetails>

    <onecall:MessageVersionNumber>1.0.10</onecall:MessageVersionNumber>

    <onecall:From>Before You Dig Partners</onecall:From>

    <onecall:RequestMedium>Web</onecall:RequestMedium>

    <onecall:UtilityID>40023</onecall:UtilityID>

    <onecall:StationCode>MBHYDRO</onecall:StationCode>

    <onecall:UtilityName>MANITOBA HYDRO</onecall:UtilityName>

    <onecall:To>Operational Contact</onecall:To>

    <onecall:JobNumber>32791</onecall:JobNumber>

    <onecall:TicketNumber>20190200180</onecall:TicketNumber>

    <onecall:PreviousTicketNumber xsi:nil="true"/>

    <onecall:SequenceNumber>41199</onecall:SequenceNumber>

    <onecall:RequestDateTime>2019-01-11T10:30:59.366224-06:00</onecall:RequestDateTime>

    <onecall:WorkToBeginDate>2019-01-24T02:00:00-06:00</onecall:WorkToBeginDate>

    <onecall:WorkCompletionDate xsi:nil="true"/>

    <onecall:IsEmergency>false</onecall:IsEmergency>

    <onecall:TicketStatus>Cancelled</onecall:TicketStatus>

    <onecall:TicketType>Regular</onecall:TicketType>

    <onecall:WorkType>Road Work</onecall:WorkType>

    <onecall:Activity>Resurface</onecall:Activity>

    <onecall:ExcavationMethod>Vacuum Excavation</onecall:ExcavationMethod>

    <onecall:ExcavationDepth><1m</onecall:ExcavationDepth>

    <onecall:ExcavationSize>456 sq m</onecall:ExcavationSize>

    <onecall:AreaMarked>true</onecall:AreaMarked>

    <onecall:UserReference>Ticket #7 January 11</onecall:UserReference>

    <onecall:WorkingOnBehalfOf>Private</onecall:WorkingOnBehalfOf>

    <onecall:WorkingForAuthority>Contractor (Subcontractor only)</onecall:WorkingForAuthority>


    -<onecall:StationList>

    <onecall:StationCode>MBHYDRO</onecall:StationCode>

    <onecall:StationCode>MTSE</onecall:StationCode>

    </onecall:StationList>

    </onecall:ReferralDetails>


    -<onecall:CustomerDetails>

    <onecall:ID>19073</onecall:ID>

    <onecall:Name>Vicki Smith</onecall:Name>

    <onecall:Company>Crown Utilities TEST ACCT</onecall:Company>

    <onecall:UserType>Contractor</onecall:UserType>

    <onecall:Phone>204-360-5099</onecall:Phone>

    <onecall:Mobile>204-795-1927</onecall:Mobile>

    <onecall:EmailAddress>vrinn@hydro.mb.ca</onecall:EmailAddress>

    <onecall:OnsiteContactName>Foreman Bob </onecall:OnsiteContactName>

    <onecall:OnsiteContactPhone>204-741-9563</onecall:OnsiteContactPhone>

    </onecall:CustomerDetails>


    -<onecall:LocationDetails>

    <onecall:Address>James Ave</onecall:Address>

    <onecall:CityTown>Beausejour</onecall:CityTown>

    <onecall:ProvinceTerritory>MB</onecall:ProvinceTerritory>

    <onecall:NearestCrossStreet>First St S</onecall:NearestCrossStreet>

    <onecall:PropertyType>Public Property</onecall:PropertyType>

    <onecall:PropertyDetail>Road/Sidewalk</onecall:PropertyDetail>

    <onecall:UrbanRural>Urban</onecall:UrbanRural>

    <onecall:MunicipalDistrict xsi:nil="true"/>

    <onecall:NearestCommunity xsi:nil="true"/>

    <onecall:RuralSubdivision xsi:nil="true"/>

    <onecall:LotNo xsi:nil="true"/>

    <onecall:BlockNo xsi:nil="true"/>

    <onecall:PlanNo xsi:nil="true"/>

    <onecall:LandGridType>LLD</onecall:LandGridType>

    <onecall:LandGrids>SW-36-12-07-E1</onecall:LandGrids>

    <onecall:Latitude>50.054336</onecall:Latitude>

    <onecall:Longitude>-96.520448</onecall:Longitude>

    <onecall:Remarks>repaving</onecall:Remarks>

    </onecall:LocationDetails>

    </onecall:OneCallReferral>

    0
    Comment actions Permalink
  • Kevin Grice

    Sher, Who are you addressing the comment with the example of MBHYDRO to?  If to me I have identified scenarios where we receive cancel tickets and scenarios where we do not receive cancel tickets.  We are hoping the naming convention using a date time stamp resolves the problem.

    Kevin

    0
    Comment actions Permalink
  • Sher Kirk

    Hi Kevin,

    My comment was a reply to Julie, but does apply to you if you are not seeing Cancels in your system.

    We are really hoping to avoid a file name change at this late date, as it would present a significant challenge to retest and reconfigure at this point.

    Can you identify for me when you are and are not receiving Cancels?

    Is it just the cancels created automatically from ticket edits that are not coming through? Are they being over-written or just not coming in?

    Thanks!

    0
    Comment actions Permalink
  • Kevin Grice

    Sher,

    The issues include:

    1. For an update ticket where the ticket type is changed from regular to emergency the cancel ticket is sent every time.  No other update tickets that change the ticket type did we get a cancel ticket.

     

    Ticket 20190200089 had update ticket 20190200120 but no cancel ticket was received.  This ticket changed from “Regular” to “Planning & Design”.

     

    Whereas ticket 20190200096 had update ticket 20190200124 and cancel ticket was received.  This ticket changed from “Regular” to “Emergency”.

     

    2. For correction tickets the only thing I noticed was that when the correction was to the field “working on behalf”, we did not get a cancel ticket.  There were no corrections for fields “user ref” or “authority” to check.  If the correction was for “onsite contact name” or “onsite contact phone” or “remarks”, we did receive a cancel ticket.

     

    Ticket 20190200082 had correction ticket 20190200116 but no cancel ticket was received.

     

    Also, I would think that if files were overwritten due to the filenames, wouldn't the Original ticket get overwritten by the Cancel ticket as it came in first?  Which is not the case, we are getting Original tickets but not always getting Cancel Tickets.

     

    Kevin

    0
    Comment actions Permalink
  • Patterson, Julie

    it was just brought to my attention that we did not receive a 2nd copy of 'updated' ticket to cancel  via .xml. we only have the original and the new ticket replacing it. chasing ghosts?

     

    0
    Comment actions Permalink
  • Sher Kirk

    My working theory at the moment is that when a ticket is edited, the automatically created Cancel of the original is not going out to FTP members - but it does seem to be getting to members receiving by Email. 
    I believe tickets that are manually canceled are correctly being transmitted to both email and FTP.

    If this is true, it would be good news. We would just need the developer to figure out the issue with FTP auto-cancels not being trnasmitted correctly.

    If is not the case, then we are back to appending "Cancel" or a timestamp to the tickets - making a big mess right before cutover.

    I am waiting to hear back from the AUS team on this issue, and will know more tonight. Fingers are crossed.

    0
    Comment actions Permalink
  • Sher Kirk

    I will give your examples to the team, Kevin. Interesting about the Regular to Emergency change cancels going through. And interesting that change is possible at all.

    0
    Comment actions Permalink
  • Kevin Grice

    Sher, just to be clear; an update ticket allows changing the ticket type, a correction ticket does not.  This is according to the edit matrix that Tasha sent me.  Also, I am assuming/hoping that the Pelican system validates any changes to dates where they have to be the correct allowable ranges on any change ticket.

    0
    Comment actions Permalink
  • Natasha Hunter

    Hello all, upon further testing we are seeing the FTP transmissions work as expected. The original ticket comes through to the ftp, if the correction comes through before the file is transferred off the ftp by the member's systems then the original is over written. If members can set their FTPs to retrieve the files every minute or so then it will prevent the original ticket from disappearing from the FTP. Some may have issues when the file hits their own systems as they may have parsing rules in place to remove "duplicate" files. If members can adjust their parsing rules to not remove duplicates then they should be able to see all versions of the tickets.  Can we move forward as is?

    Note that we WILL still be moving ahead with getting the file name to include the time stamp but we would like to hold off on this until after cutover as extensive testing will be needed. 

    0
    Comment actions Permalink
  • Patterson, Julie

    BC Hydro- we have identified inconsistent response from Pelican software  around Edit tickets . some get notification to cancel, some do not, sometimes multiple copies of the files are sent. sometimes the .xml shows up a bit later. there is no correlation to ticket type Correction or Update.

    1
    Comment actions Permalink
  • Geoff Moen

    MB Hydro - we have encountered and are encountering the same issue. The FTP transmissions are not working as expected. 

    1
    Comment actions Permalink
  • Vicki Rinn-Stechkewich

    MB Hydro -  our most recent test of ticket edits performed yesterday included 3 Corrections and 3 Updates.  We received only 2 Cancel Tickets (for 2 of the Updates).  The issue persists.     

    0
    Comment actions Permalink
  • Patterson, Julie

    BC Hydro: why are we keep going back to hinging every fix on a file name change? I am not a technical it support but have worked with these programs a long time. to keep hanging everything on the file name changes we are going to run out of options. currently we have ticket numbers with version numbers and a fully functioning .XML that does what it needs to do based on what is on the specific status/ticket type is. why not go back to what you know what works and add that to the .XML? I am sure my IT support would be able to explain it better...

    0
    Comment actions Permalink
  • Sher Kirk

    The Ticket Edits and Cancels are now transmitting and being received correctly, The bug is dead. 
    Thanks for your help everyone. Special nod to Julie and Kevin for helping us work through this one.

    -1
    Comment actions Permalink

Please sign in to leave a comment.