<?xml version="1.0"?>
<ArrayOfFBEvent xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <FBEvent>
    <User>Justin Richardson</User>
    <Comment>Tested with dp 4.2.322,4.0.1117.50033. per Dans reccomends...

2 SPS with one ecm ,and channels only assigned from one SPS .

Armed triggered and recorded data

Verified Dp log shows  dasconfigs file was written and dp shows no errors ..
....   



 
</Comment>
    <StatusString>Closed</StatusString>
    <TimeStamp>2024-01-11T22:42:53Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>Closed</Status>
  </FBEvent>
  <FBEvent>
    <User>Justin Richardson</User>
    <Comment />
    <StatusString>Assigned</StatusString>
    <TimeStamp>2024-01-10T16:16:54Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-01-02T16:22:40Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>ReleaseNoted</StatusString>
    <TimeStamp>2023-12-19T21:23:30Z</TimeStamp>
    <ReleaseNote>Improves logging for situations where the XML configuration may not get written to the PC</ReleaseNote>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-12-07T21:30:15Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>3.3/4.0/4.2@49936
 
SQA can not directly test the conditions which produce the new warning as they can't be normally duplicated, however it still should be tested that there aren't adverse affects from the patch so
 
1) a test with 1ECM + 2SPS with channels only assigned on 1 SPS should not produce the warning about config file not written and it should produce the log message about config file written.</Comment>
    <StatusString>Resolved</StatusString>
    <TimeStamp>2023-12-07T21:28:30Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>Resolved</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>Subject:
 please review http://manuscript.dts.local/f/cases/35577/WriteXmlConfigToPC-improvements    
From:
 Dan McFadden &lt;dan.mcfadden@dtsweb.com&gt;    
Date:
 12/6/2023, 2:55 PM        
To:
 DTSSoftwareDev &lt;DTSSoftwareDev@dtsweb.com&gt;    

 
 
 
Jerry, John,
 
Here is a patch for 3.3 for an issue from Toyota Boshoku;
 
Toyota reported that occassionally an SPS would not write an XML file into the Test\DASConfigs directory.  If there is corruption on the file on the SPS this file is needed to re-upload to the DAS to download, so they are concerned if the file is not written they won't be able to download.
 
I was not able to duplicate their issue, but I think there's a lot we can do to alert the user if this happens.
 
first in StoreXmlConfigPC I added a way to notify via the UI that an error has happened so that they know they shouldn't proceed with the test.
 
I did this by adding an event handler to APILogger for raising errors so that DataPRO or any other application can make use of that event handler to be notified on errors.  I chose it to do it this way rather than use the PageErrorEvent as one of the things we discovered during the DASFactory on linux experiment is that microsoft and windows event handling doesn't work so hot on linux and will tend to break things.
 
DataPRO in turn then adds a handler.  It does use microsoft event handling at that point, but once we are in the windows UI, maybe that's okay.
 
in AsyncConfig in SLICE2 I keep a variable bFileWritten and set it to true after the file should have been written.  I use this on the offhand that an exception was thrown during AsyncConfig that would cause it to bypass the file write silently.  In my testing I'm not sure that _can_ happen, but the new code should handle it if it does happen.
 
there's no good way to test the code other than purposely throwing exceptions.
 
In SLICE2.cs if you throw an exception right before:
 

bFileWritten = true;
 
 
 
it should 1) log the error, and 2) show a dialog indicating the file wasn't written to the pc:
 
 
the second place you can throw an exception easily to duplicate the behavior is in SLICE2.cs before
 
                        APILogger.Log($"DASConfig file written: {fileName}");
 
if you don't throw either exception and it writes the file you should see the statement above in the log.
 
The changes are only for SLICE2 and SPT is excluded as it has it's own asyncconfig.
 
The patch will need to be very different for DP 4.0 and 4.2 as this code is very different in 4.0 and beyond.
 
It should also be tested with an unused das in the test.  It should not warn about the file not being written if a DAS is unused and is still included in the test.
 
 
 
 Attachments: 
    DTM_35577_PCFileWarn.patch 85.2 KB</Comment>
    <StatusString>Assigned</StatusString>
    <TimeStamp>2023-12-06T22:56:56Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>added this logging to SLICE2_Base.AsyncConfigure:
 
APILogger.Log("exception during configuration",ex);
 
finally added a call to notify if asyncconfig was called on a non SPT SLICE2 and it doesn't write the file to raise an error to the UI:</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-12-06T22:23:37Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>now will log this on success:
 
 APILogger.Log($"DASConfig file written: {fileName}");
 
or raise this error on failure in SLICE2.SLICE2ConfigAttributes.StoreXmlConfigPC
 
$"Failed to write DAS configuration file to PC.  Please contact support"
 
 
note that this is only displayed, it doesn't change program flow, doesn't fail any activities</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-12-06T21:35:54Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Assigned</StatusString>
    <TimeStamp>2023-12-05T21:12:34Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-12-05T20:01:29Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Assigned</StatusString>
    <TimeStamp>2023-12-05T18:04:24Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>as indicated in PDF</Comment>
    <StatusString>Opened</StatusString>
    <TimeStamp>2023-12-05T18:04:23Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>Opened</Status>
  </FBEvent>
</ArrayOfFBEvent>