jdevalk's account

Here's what I am trying to achieve: ESign a document that has * 1 signer by email aka [Client.Capture1] * 2 group signers (Group1 and Group2) aka [Group1.Capture2] and [Group2.Capture3] The document is uploaded with EnableExtraction so the Groups are extracted by ESignLive. Result: On SDK 10.13 (latest from GitHub) this does not work without patching the SDK. Update: I fixed the issue but I needed to patch the actual .NET SDK to make it work, as in the translation between ApiDocument to SdkDocument some piece of information is not converted into the SdkDocument that is then used to lookup the Approvals of the Document you just uploaded. My patch is below. I do not know if this is the right patch to do, but for now it works. This is my code that I have now to call ESignLive API: (Note this is copy paste as I do not want to post the code to my actual package builder but this is what it produces in the end) PackageBuilder packageBuilder = PackageBuilder.NewPackageNamed(packageName) .DescribedAs(packageDescription) WithSigner(SignerBuilder.NewSignerWithEmail(clientEmail) .WithFirstName(clientFirstName) .WithLastName(clientLastName) .WithCustomId("Client") .SigningOrder(1)); WithSigner(SignerBuilder.NewSignerFromGroup(new GroupId("ed4d46cb-0d12-4a95-bdba-6a2ee8e17d6f")) .WithCustomId("Group1") .SigningOrder(2)); WithSigner(SignerBuilder.NewSignerFromGroup(new GroupId("fea96302-8e3d-43a9-8882-e28cb73e4b9")) .WithCustomId("Group2") .SigningOrder(3)); WithDocument(DocumentBuilder.NewDocumentNamed(document.Name) .WithDescription(document.Description) .FromFile(path) .EnableExtraction()) .WithInjectedField(FieldBuilder.TextField() .WithId("InjectedField") .WithName("InjectedField") .WithValue("TestValue") >>>> FAILS >>>> PackageId packageId = _eslClient.CreatePackage(documentPackage); Fails with NullReference exception in SignatureConverter.ToSdkSignature() Note 1 : If you call it with => NewSignerFromGroup(new GroupId("Group1")) This does not work in the sandbox environment, you get a HTTP ERROR 500 : internal API error So the only way to make it work is by specifying the GUID Note 2: By specifying the GUID in NewSignerFromGroup and because it is using EnableExtraction, now the API doesn't seem to be able to extract that "Group1" is a ESignLive Group. Because of this I have to call it with "WithCustomId("Group1")" and then it seems the extraction does work. Patch made in SDK: I have traced the problem I am experiencing to the following: It Creates the Package fine, and then proceeds to upload the document. After it Creates the package, the SDK gets the ID of the new package back and does GetPackage(id) on it, that will result in a copy of the Package (Api Package) as it then exists on the server. It will then proceed to upload the PDF document, and that will complete successfully. It will get a API Document back. The API Document needs to be converted to an SDK Document. The part failing here is when it tries to resolve the API Document approvals (signatures) to the package roles. Note it resolves the roles against the copy of the package that was returned by GetPackage() not the package that we uploaded originally. In the mapping between API Package to DocumentPackage, when it creates the Roles, it will miss copying a piece of information that was in the original package uploaded to ESignLive. This piece of information is the Group name (we have the ID though, the GUID) If the patch is not made, it goes into DocumentConverter, and that tries to Add the signatures. The signatures creation will call SignatureConverter.ToSdkSignature() and in there it will try to compare Package Role ID's against Document Approval ID's In the API call to upload a document, the JSON representation of the Document returned only states Role: "Group1". And as said above the fact that "Group1" equals a role is lost from converting API PAckage to SDK Document Package. Patch is to change this code: (DocumentPackageConverter.cs: line 176) foreach (Silanis.ESL.API.Role role in apiPackage.Roles) { if (role.Signers.Count == 0) { packageBuilder.WithSigner(SignerBuilder.NewSignerPlaceholder(new Placeholder(role.Id, role.Name))); } else if (role.Signers[0].Group != null) { packageBuilder.WithSigner(SignerBuilder.NewSignerFromGroup(new GroupId(role.Signers[0].Group.Id))); } else ..... Into this: foreach (Silanis.ESL.API.Role role in apiPackage.Roles) { if (role.Signers.Count == 0) { packageBuilder.WithSigner(SignerBuilder.NewSignerPlaceholder(new Placeholder(role.Id, role.Name))); } else if (role.Signers[0].Group != null) { /// THE CODE BELOW WithCustomId() injects the custom ID that comes back from ESignLive API Document into the SDK Document, else it gets lost. SignerBuilder signerBuilder = SignerBuilder.NewSignerFromGroup(new GroupId(role.Signers[0].Group.Id)) .WithCustomId(role.Signers[0].Group.Name); packageBuilder.WithSigner(signerBuilder); } .....

Another note that the Groups are not created through the API but they are created in the ESignLive web console / account administration. The EnableExtraction I assume to be able to resolve Groups in uploaded documents created both through the API and through the Web console / account administration. Also it seems to me purely a .NET SDK mapping issue as when you inspect the JSON from the package returned and the document returned after upload, they do resolve correctly and all the information is there. Also after upload if you inspect the packge in eSignLive console in Drafts then you can see the fields were resolved correctly (extracted) to the Groups by ESignLive. After making the patch above to the SDK code, you can complete the signing ceremony and no more NullReference error is thrown with converting the Api Document to the Sdk Document in setting up the package.

That is kind of the direction we were going in. The only drawback with the X in the injected field is that our customer now chooses to maintain 2 sets of PDF forms. One for the auto-fill by eSignLive and another PDF form that they will use when sitting face to face with a client of theirs. The first scenario the form has no checkbox, the 2nd scenario, the form will have a checkbox. While this works, I am not terribly excited because it does mean duplication of the form assets, unless we can find a way in PDF Acrobat to overlay a Label with a checkbox, without one interfering with the other.