Set Document's field inside DocumentList to String value


Platform: SoftwareAG WebMethods 8.2
The problem: I have 2 DocumentList’s. One of them contains XOPObjects the other Strings. I have to convert XOPObject to String and copy it to the other DocList’s correspoding String field. What happens? Nothing. The String field remains entry while the XOPObject’s base64string is nicely generated.

Performed steps with Given DocList:A(Source with XOP) DocList:B(Target with String field)

  1. Loop over A
  2. Create Base64String from XOPObject using pub.soap.utils:getXOPObjectContent
  3. Call pub.flow:debugLog to check if the base64String is generated [OK]
  4. Generate index variable from $iteration with pub.math:subtractInts as index:=$iteration-1 [OK]
  5. Perform map step from base64String to B’s String field with index set to %index% [base64string is not even on the pipeline at this point runtime. In designer/developer its there…]
  6. After loop
  7. pub.xml:documentToXmlString to generate xml representation of the B document
  8. pub.flow:debugLog
  9. Nothing is in the String field…

Any idea what is going wrong in here?

Example log:

[204] </sm9chm:model>
[203] </sm9chm:instance>
[202] </sm9chm:attachments>
[201] <cmn:attachment xmime:contentType="application/xop+xml" action="ADD" name="Attachment_2" type="application/xop+xml" len="1088"/>
[200] <sm9chm:attachments>
[199] <sm9chm:middle type="Structure"/>
[198] <sm9chm:description.structure type="Structure"/>
[197] <sm9chm:header type="Structure"/>
[196] <sm9chm:instance>
[195] </sm9chm:keys>
[194] <sm9chm:ChangeID type="String" mandatory="true" readonly="true">C000004225</sm9chm:ChangeID>
[193] <sm9chm:keys>
[192] <sm9chm:model>
[191]<sm9chm:UpdateTsiChangeRequest attachmentInfo="true" attachmentData="true" ignoreEmptyElements="true" xmlns:cmn="" xmlns:sm9chm="" xmlns:xmime="">
[190]2014-02-14 10:16:01 MET [ISP.0090.0003C] <?xml version="1.0"?>
[189]2014-02-14 10:16:01 MET [ISP.0090.0004C] >>>>> EXTRACTED: -- QGVjaG8gb2ZmDQoNCnNldCBTT0FQVUlfSE9NRT0lf....

What did I expect?
In line [201] the <cmn:attachment is not self closing but the base64 string is right the contents of it.