cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5594
Views
45
Helpful
26
Replies

UCCX 2020 holiday.xml

Julie Oblak
Level 1
Level 1

I have been updating my holiday.xml files for years now so they are known working from last year.  I updated them so today was a holiday.  It did not work and I am wondering if there is something that the format does not like for this year 2020?  This is a snippet of the file.

<Holidays>
<Holiday1>
<Holiday>01/01/20</Holiday>
<StartTime>00:00</StartTime>
<EndTime>23:59</EndTime>
</Holiday1>
<Holiday2>
<Holiday>04/10/20</Holiday>
<StartTime>11:59</StartTime>
<EndTime>23:59</EndTime>
</Holiday2>
<Holiday3>
<Holiday>05/25/20</Holiday>
<StartTime>00:00</StartTime>
<EndTime>23:59</EndTime>
</Holiday3>
<Holiday4>
<Holiday>07/04/20</Holiday>
<StartTime>00:00</StartTime>
<EndTime>23:59</EndTime>
</Holiday4>

1 Accepted Solution

Accepted Solutions

Does your original XML file use a 4-digit year instead of the 2-digit, as in your sample? You may want to refer back to the original XML that worked previously.
4/10/20 does not equal 4/10/2020, either ;-)
-Sean

View solution in original post

26 Replies 26

Anthony Holloway
Cisco Employee
Cisco Employee

Based on only that snippet of XML, yes, you are missing the closing Holidays tag.

<Holidays>
	<Holiday1>
		<Holiday>01/01/20</Holiday>
		<StartTime>00:00</StartTime>
		<EndTime>23:59</EndTime>
	</Holiday1>
	<Holiday2>
		<Holiday>04/10/20</Holiday>
		<StartTime>11:59</StartTime>
		<EndTime>23:59</EndTime>
	</Holiday2>
	<Holiday3>
		<Holiday>05/25/20</Holiday>
		<StartTime>00:00</StartTime>
		<EndTime>23:59</EndTime>
	</Holiday3>
	<Holiday4>
		<Holiday>07/04/20</Holiday>
		<StartTime>00:00</StartTime>
		<EndTime>23:59</EndTime>
	</Holiday4>
</Holidays>

 

This is just a snippet and my actual file does have the ending tag. Thanks for noticing. If it would be helpful I can include the whole thing.

So, you didn't mention whether or not this worked on 01/01/20. If it did, then your scripting logic should be fine, and it is your XML document at fault. If it didn't, or you don't know, then maybe the logic of the script is such that it only worked in 2019, and something about 2020 is different. Here's a way you can validate if your XML is good or not. Create a brand new blank script and create 1 variable of type Document. Call it what you want, and set the value to DOC[yourfilenamehere], replacing in your actual filename. Then in the body of the script, use the Create XML Document step, and use that variable for both the input and the output, and then press F10 on your keyboard to debug the script, stopping when the red hits the End step. Look at your variable down in the variable pane. If you can see the XML contents of the file, it worked and is fine. If you see anything else, your XML file is bad (as in bad formatting).

To the best of my knowledge it did work on 1/1/2020 but I can't be sure.  This file was copied from the one I used in 2019.  I have a test document that I I am using to test the holiday.xml file in.  I will try what you have suggested and hopefully can figure this out.

Does your original XML file use a 4-digit year instead of the 2-digit, as in your sample? You may want to refer back to the original XML that worked previously.
4/10/20 does not equal 4/10/2020, either ;-)
-Sean

I think between the leading zeros and the year format being wrong one of the two was the solution.  I think the leading zeros was it.  Not to mention my impatience.  I am working from home and am wondering if the files were not updating as fast as I expected them to.  However, your help is greatly appreciated.

Sean Lynch
Level 7
Level 7

...if this is only a partial snippet of what the XML file looks like--which I'm guessing--I'm not entirely sure.
But, check your start and end tags [<Holidays>… </Holidays>]. 
Even more, you have no XML declaration at the top. 
...You also have leading zeros in your data elements.  Not sure how your script operates, but my holiday scripts do not use leading zeros in the days/dates or months.
Just a few ideas to check.
Hope this helps.
-Sean

Yep this is partial and I do have the ending tag. I also checked the tags to be sure there is a start and an end. I did try it with and without the leading zero's as I know that was an issue for me in the past. I checked my 2019 files from last year and it did not have an XML declaration at the top so not sure what that would be? Thanks

...then my next question is the application / script referencing the correct XML data file from the "refreshed" repository directory?

 

-Sean

...one addition.  It's important to remember that XPath on UCCX reads XML files as a STRING variable.  So if your holiday script is using a short date (for today) to evaluate against an XML data source:

04/10/20 does not equal 4/10/20

 

2020-0410-sampleHolidayXML.png

 

...I also highly recommend using something like Notepad++ with XML tools, to check the syntax of any XML file before uploading it to the doc repository.

-Sean

Repository is accurate. I use Notepad++. I removed the leading zeros. Added <?xml version="1.0" encoding="ISO-8859-1"?> to the file as that is what I have on others but I'm unsure if that is accurate. It still does not work. I also tried what you shared and that as well does not work.

There should be no problem with your XML declaration. ISO-8859 is just an older standard. That should still work on UCCX. What is happening in your interactive debug? Is your holiday check a subflow? You can run it interactively in the editor without a call to see where it is failing. I don't mind helping troubleshoot this if you would like assistance.

-Sean

Actually not only do you not need the declaration, if you try to use that ISO one, UCCX just switches it to UTF-8 anyway.

Ha!  Thanks.  That's awesome.  More fodder for UCCX trivial pursuit... Hee hee hee...  

Thanks again, Anthony--always good info...

-Sean