Property-Set-Stream corrupts HTML by appending <div> element

User Experience
, , , ,
1

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:

  1. In an automated flow, so the user would be a Pega operator, e.g. Agent(…), so pxCreateOperator is System
  2. 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

elements seems to be a known issue so I hope there will be a solution for this.

2

Another workaround is using expressions to remove anything that comes before and after the actual content of our HTML-section, i.e. to remove the auto-generated

<div> elements:

*@replaceAll(param.xsltTemplate,@substring(param.xsltTemplate,0,@indexOf(param.xsltTemplate,"<?xml version")),"")* 

for anything that comes before, and

*@replaceAll(param.xsltTemplate,@substring(param.xsltTemplate,@indexOf(param.xsltTemplate,"</xsl:stylesheet>")+@length("</xsl:stylesheet>*

“),@length(param.xsltTemplate)),”")

for anything that comes after the actual content of our HTML-section (stored in param.xsltTemplate).

3

With the help of Pega support team, the root cause for this behavior could be elaborated and another solution was found.

The reason for the

element being appended is automatic templatization, which can be disabled and reset in two additional steps so to avoid corrupting the HTML stream. To do so, the activities pzSetUITemplateStatus and pzResetUITemplateStatus can be called before and after the Property-Set-Stream method, respectively (also see pyAttachAsPDF for reference).

However, calling these internal activities will in turn lead to the maintainability warning

"Internal activity

Use of an internal activity from another ruleset is not recommended. The calling signature of these rules may change over time, or they may be deprecated completely. Consider using non-internal activities instead."

that can not be resolved by justifying it: “Justification for this incorrect practice is not allowed”

In a preliminary test, this warning has brought the guardrail score of the corresponding branch down from 100 to 41 so it cannot be merged.