Property-Set-Stream corrupts HTML by appending <div> element
Use case In order to create a custom PDF in one of our apps, we use an activity that in turn will call the activity HTMLToPDF etc. In a previous step, we use the method Property-Set-Stream to store the content of an HTML-section (stream of class Rule-HTML-Section) in a parameter. We run the activity in two different scenarios:
- In an automated flow, so the user would be a Pega operator, e.g. Agent(...), so pxCreateOperator is System
- From an assignment, so the user would a local operator, e.g. Jon Doe (so pxCreateOperator is Jon.Doe)
The 1st scenario works fine and the parameter value equals the content of our HTML-section.
Our HTML-section has the following outer structure:
<?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet ...
...
</xsl:stylesheet>
Problem In the 2nd scenario, the value stored in our parameter by the Property-Set-Stream method no longer matches the content of our HTML-section. Instead, we found the method to wrap the content into the following <div> element (printed italic), making the parameter value unusable for the steps that follow:
<div data-template-name='pxNonTemplate' data-template-instance-id='1210215282170846' CLASS='template-root-marker'><div id='1210215282167375' style='display:none'>
Use case In order to create a custom PDF in one of our apps, we use an activity that in turn will call the activity HTMLToPDF etc. In a previous step, we use the method Property-Set-Stream to store the content of an HTML-section (stream of class Rule-HTML-Section) in a parameter. We run the activity in two different scenarios:
- In an automated flow, so the user would be a Pega operator, e.g. Agent(...), so pxCreateOperator is System
- From an assignment, so the user would a local operator, e.g. Jon Doe (so pxCreateOperator is Jon.Doe)
The 1st scenario works fine and the parameter value equals the content of our HTML-section.
Our HTML-section has the following outer structure:
<?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet ...
...
</xsl:stylesheet>
Problem In the 2nd scenario, the value stored in our parameter by the Property-Set-Stream method no longer matches the content of our HTML-section. Instead, we found the method to wrap the content into the following <div> element (printed italic), making the parameter value unusable for the steps that follow:
<div data-template-name='pxNonTemplate' data-template-instance-id='1210215282170846' CLASS='template-root-marker'><div id='1210215282167375' style='display:none'>
<?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet ...
...
</xsl:stylesheet>
</div></div><div template-scripts><script>if ( window.name && window.name.indexOf('yuiIO') == 0 ){ window.onerror=function(){return true}}</script><script>pega.ui.jittemplate.mergeBigData({"pyWorkPage":{"$pxNonTemplates":{"d99bc0cb8f2994f8e423f4fa1ba17b1b7bfb501a_1":"1210215282167375"}}},"TABTHREAD6/ACPRIMARY_0");<script><script>pega.ui.jittemplate.addMetadataTree([{"NTId":"1210215282167375","NTRef":"d99bc0cb8f2994f8e423f4fa1ba17b1b7bfb501a_1","pyName":"pxNonTemplate","pyInstanceID":"1210215282170846","pzPrimaryPage":"pyWorkPage"}]);</script></div>
Current workaround Instead of running the activity directly from an assignment, we wrap into another activity that calls the Queue-For-Processing method. This way, our actual activity is again being run by a Pega operator, i.e. Queue processor(...), or pxCreateOperator again is System. The downside of this workaround is, however, that the local operator performing the assignment will loose their lock to the System operator and thus will have to perform the assignment again.
Pega appending <div> elements seems to be a known issue so I hope there will be a solution for this.