Managing XML data in a process

[wasi26]

So what I have spent the morning trying to do is to get an XML variable to hold data from a form through several steps.  So Once the user fills out the initial form in Workspace, the process is invoked.  The first step is to process the data, which I do by using a Set Value operation to populate several fields on the next form that will show up (we'll call it the update form) and to write some of those values to an xml variable.  The form is a xfaForm variable with schema embedded and the XML variable also has a schema associated with it.  The schema on the variable corresponds to the bottom structure of the form which I named 'History'.  The idea is that, as this form is routed to different people (within the scope of this process instance) the data they input into the form will be written to this xml process variable which I can then use to populate the history section in the bottom.  The problem I'm having is that it works the first time around (when the first person gets the form and fills it out, but the next time the variable is being overwritten.  The idea was that in this dynamic form, as the xml variable grows so will the form.  Any body have any suggestions?  Jasmin you helped me out a while back with a similar issue dealing with the query for multiple rows operation and me needing the form to grow depending on the number of rows being returned.  Similar concept except we're not going to the database, we're trying to use the xml variable to build an xml document that'll be data provider for those fields....  Any help is welcome....Please

[wasi26]

Can anyone help me with this?

[Former Community Member]

Which version of LiveCycle ES are you running? There was a problem in 8.0 that caused XML nodes to get clobbered.

Steve

[wasi26]

We're running 8.2

[Former Community Member]

Sorry. I also meant to ask if you post the XPath that you are using to replace the XML node.

[wasi26]

No problem. The initial XML stored in the xml variable looks like this:

<History>
    <IssueHistory>
        <Department>my</Department>
        <ReferredTo>stephanie</ReferredTo>
        <SubmittedBy>me</SubmittedBy>
    </IssueHistory>
    <IssueHistoryBottom>
        <comments>Why doesn't she like me?  I like her.... What have I done?</comments>
    </IssueHistoryBottom>
</History>

The xpath I was trying to use to add information was:

/process_data/XMLData/History/IssueHistory       for the Location

/process_data/FormData/object/data/xdp/datasets/data/CI/page1/IssueSummary/Middle/SubmittedBy   for the expression

My thinking was that in adding it to the IssueHistory node, it would add another SubmittedBy but it didn't.  But now looking at it I think I need whole other History node to do what I trying to do.  But my problem is that it continues to overwrite the previous data in the xml variable.  How can I insert the new data at the top?

[Former Community Member]

Hi,

You are right. You'll need to create a new <IssueHistory> element first and then use the set value with /process_data/XMLData/History/IssueHistory[1] type of syntax to assign value to the newly created element.

I think there is no way to add an arbitary xml structure (something like 'create element as child of that element') in livecycle's xpath expression builder or basic components.

Obviously what you can do is to write some java code to create the xml structure and put it in Script component. Once you do that then use the set value to put values there.

Alternatively I know of a component that is designed just to do this history creation and it does all of the above. You just put that component after your user step and then you can configure what to put in history section.

Have a look at - http://www.avoka.com/avoka/components/TaskHistory/TaskHistory.shtml

cheers,

Parth Pandya

http://livecyclekarma.wordpress.com/

[wasi26]

Thanks for your help with this.

[Former Community Member]

Hi Wasi,

What did you endup doing?

[wasi26]

Well because this was rushed, we went ahead and wrote to the database, and pulled back information when we needed it.  When we get some more time, we'll probably have to re-work this solution with one that doesn't need to write to the DB between each step of the process.  But for now it works....