That would certainly make the InfoPath side of things cleaner. Doesn't it defeat the point of SmartObjects though, since you are now storing data in your XML fields?
I'm using smart objects to persist the data for reporting purposes, and to help propogate the data through my workflow (where it is typically read only, as a reference to the user). It is not a good practice to rely on InfoPath to be your data source, particularly when assigning InfoPath client tasks to multiple slots as it makes a copy of the InfoPath form for each slot.
Tim,
How is the process initiated? Is it initiated by an InfoPath form? It does not sound like it. There could be an error with referencing the process level XML because it is null, or something else. Hard to tell from here without seeing a process definition.
However here is my two cents. I really would not populate the InfoPath XML in the K2 process. For all my processes I integrate the SmartObject method into the InfoPath form, call the method and then update main data source via rules when the InfoPath form is opened. If you have lots of data, yes you have to do a lot of clicking but one of developers recently just cracked open the .xsn, went to the manifest and just built the rules manually and did it in 10 mins. We had 50 fields.
The real reason why you may want to do this is because if you InfoPath form is referencing data that may be updated by other places, there is a possibility that an InfoPath process may sit for two days and by the time the users opens up the form the data is old.
Another issue you will run into is if they have collections of repeating data they need to populate into their form. You cannot do that with a SmartObject event on the K2 process definition. If you wanted to do the population of repeating data in the XML, you will have to write some custom code. This is not the case when using the SmartObject method directly on the form.
So my best practice is to do what you are trying to do on the form.
As well, if you really want to try to figure out what is going on, try writing a code event handler using the SmartObject API and populate the XML.
Jason
Thank you Jason, you made a good case for moving that logic to the form. I was hoping to avoid this approach, as it just seems a bit tedious, but it looks like it would pay off in the long run particularly when opening the form outside of the process (didn't think of that).