AnsweredAssumed Answered

XOG out corrupted by contentPack tags

Question asked by steveVanArsdale on May 15, 2014
Latest reply on May 16, 2014 by steveVanArsdale

Has anyone else encountered this?  While XOG'ing out a workflow process containing one or more GEL scripts containing XOGs...

" ... XOG OUT adds:
Four additional lines, which are cleanly inserted into the last GEL script in the XOG write file, within the <XOGOutput> tags:
    <Object type="contentPack"/>
    <Status state="SUCCESS"/>
    <Statistics failureRecords="0" insertedRecords="0" totalNumberOfRecords="2" updatedRecords="0"/>
    <Records/>

Which called Object type twice, so the XOG in the GEL fails. But these lines are not in the original GEL script.
Deleting the four lines before doing the XOG-in solves the issue.

This is occurring on two different ver.13.1 systems, and can be re-created consistently. As one of the gifted Clarity techicians here said, "Really Odd". 

ps: We have discovered that this does not have anything to do with the 'content pack' XOG read script. The same issue occurs when XOG'ing out the workflow process with the bpm._process read script.  So it may be something in the GEL itself within the workflow process.  We noted that the XOG write file that is being output does not have the typical 'SUCCESS' tags (Object, Status, Statistics, Records) at the end.  Perhaps something in the xog text that the GEL script is parsing, is triggering the XOG out process to insert the 'SUCCESS' section too early in the XOG write file?  We also noted that this is occurring consistently using the xog.client in ver.13.1. Has anyone encountered this before?

Outcomes