Also make sure that you do not sign the _K2 node in the IP form. K2 changes these values and therefore would invalidate the form. Also make sure that you do not modify the XML data anywhere within your process via Server Events or other events.

 

Make sure that the form works fine without K2 i.e. sign and save the form to the save location that K2 would upload the form to. If it opens then at least we have narrawed down the focus area. Then you can edit the code item for the Infopath client event to check where the XML is modified and whether the result invalidates the form. If you do find an issue then I would urge you to log a ticket on the support portal (http://portal.k2workflow.com)

 

---

Hi rbakkers

The digital signatures that gets removed when you deploy your K2 process is a known issue. It has been logged and according to our system, this will be fixed in a future release.

Hope this helps,

---

My first reaction would be that K2 is using the XML document given to it from InfoPath as volatile (changing) data storage. I am not sure if this is the problem, but here is a potential fix:1. Create your InfoPath document and create the associated process using it.2. Open document from within the Visual Studio solution explorer.3. You should see the _k2 field in your XML.4. Tools -> Form Options... -> Digital Signatures 5. Select "Enable digital signatures for specific data in the form"6. Add all the fields in the document, except for _k2, the root group, and the signature(s) groups.7. Press Ok.This will allow K2 to alter the data in the document without affecting fields that are designated as signed. Please test this, as I don't have a suitable environment. If you find that this works, I recommend that you place all form data under a group within the form (so that the user does not need to sign each field independantly). I have attached a .xsn that demonstrates the concept.This is a bit obvious, but in any case, any alterations to the data made by your process will break the signature - it is what they are designed for. If you need to change the data during the process, something that may work is a SmartObject that can store the IP document as the user enters it before any changes are made and then (via an association to itself) the IP document when the process it finished with it. A simple query will return both document and you can check them by hand.The alternate answer is a little more complicated and dissapointing.As Bob explained it has to do with Whitespacing in XML. Taking as a tab and s as a space the following example will demonstrate the concept clearly:InfoPath: My Text .Net:ssssssMy TextssIIRC the .Net XML Writer uses two spaces as the default indentation sequence - and Bob indicates that InfoPath uses a single tab as a indentation sequence. However, correct XML signing requires that the document be stripped of insignificant whitespace before signing:My TextIf InfoPath is not doing this, it is a *bug in InfoPath* - signing XML is a fragile procedure, so it would be best to find out how InfoPath signs documents beforehand. Obviously, it may be nessecary to alter the behaviour of K2 is Microsoft is not willing to fix this.HTH.

---

My first reaction would be that K2 is using the XMLdocument given to it from InfoPath as volatile (changing) data storage. I amnot sure if this is the problem, but here is a potential fix:

1. Create your InfoPath document and create theassociated process using it.

2. Open document from within the Visual Studio solutionexplorer.

3. You should see the _k2 field in your XML.

4. Tools -> Form Options... -> Digital Signatures5. Select "Enable digital signatures for specific data in the form"

6. Add all the fields in the document, except for _k2,the root group, and the signature(s) groups.

7. Press Ok.

This will allow K2 to alter the data in the documentwithout affecting fields that are designated as signed.

Please test this, as I don't have a suitable environment.If you find that this works, I recommend that you place all form data under agroup within the form (so that the user does not need to sign each fieldindependantly). I have attached a .xsn that demonstrates the concept.

This is a bit obvious, but in any case, any alterationsto the data made by your process will break the signature - it is what they aredesigned for.

If you need to change the data during the process,something that may work is a SmartObject that can store the IP document as theuser enters it before any changes are made and then (via an association toitself) the IP document when the process it finished with it. A simple querywill return both document and you can check them by hand.

The alternate answer is a little more complicated anddissapointing.

As Bob explained it has to do with Whitespacing in XML.Taking as a tab and s as a space the following example will demonstrate theconcept clearly:

InfoPath:

<myXml>

<myElement>

My Text

</myElement>

</myXml>

 

.Net:

<myXml>

ss<myElement>

ssssMy Text

ss</myElement>

</myXml>

IIRC the .Net XML Writer uses two spaces as the defaultindentation sequence - and Bob indicates that InfoPath uses a single tab as aindentation sequence. However, correct XML signing requires that the documentbe stripped of insignificant whitespace before signing:

<myXml><myElement>MyText</myElement></myXml>

If InfoPath is not doing this, it is a *bug in InfoPath*- signing XML is a fragile procedure, so it would be best to find out howInfoPath signs documents beforehand. Obviously, it may be nessecary to alterthe behaviour of K2 is Microsoft is not willing to fix this.

HTH.

---