XOG out corrupted by contentPack tags

[Anon Anon]

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?

[Anon Anon]

While we have not found the cause, I'd like to post that we have the work-around.

If the process that is being XOG'd out has a GEL script that builds a XOG file,  and that XOG file contains a <XOGOutput> section, then the xog.client inserts into the XOG write file, within the GEL and cleanly into the <XOGOutput> section,  a duplicate set of tags (Object, Status, Statistics, and Records).   

Removing the <XOGOutput> section from the GEL script eliminates the extra tags from being inserted.  

[Deactivated User]

Just wondering again...

Aren't those line nomrally created at the end of XOG read output file? I have also XOGed the files back without removing those lines.

Though I have only one samle file from the process with GEL script in it to create the xml file and then  XOG the  xml file in.

In that I have removed the XOGouput section. Below is the XOG out put for reading groups.

Are you saying the XOG write fails if you do not remove the lines?

Martti K.

 

[Anon Anon]

....Are you saying the XOG write fails if you do not remove the lines?

Martti K.

 

 

Hello, Martti.  No, it's a LOT more fun.

The XOG write file works as designed, no errors. The XOG read however, had inserted the four extra lines DIRECTLY INTO THE GEL SCRIPT WITHIN THE PROCESS. 

 

Then when the user runs the workflow process, it fails. Even if that process with the GEL script XOG has worked hundreds of times before. And when one checks the GEL, it validates, and when one examines the XOG write file, it checks out too, because the XML syntax is intact.However, when the process is run and the GEL script in the process parses each XOG write file, it puts that second set of <XOGOutput> tags discreetly into the XOG write file before running it. Then the XOG processor encounters a second <Object> tag, and fails.

So: when we know what to look for, it's easy to find. The question is, why is it happening?  Is it a local issue? Or is it caused by the xog.client?