为嵌入式签名创建收件人视图时的 UNKNOWN_ENVELOPE_RECIPIENT答案

【问题标题】：UNKNOWN_ENVELOPE_RECIPIENT when creating recipient view for embedded signing为嵌入式签名创建收件人视图时的 UNKNOWN_ENVELOPE_RECIPIENT
【发布时间】：2020-01-13 16:45:07
【问题描述】：

在创建的许多信封中，我们有一个无法为嵌入式签名创建收件人视图 URL。在下面的示例测试中，两个信封 ID 之一失败并显示

    DocuSign.eSign.Client.ApiException : Error calling CreateRecipientView: {
       "errorCode": "UNKNOWN_ENVELOPE_RECIPIENT",
       "message": "The recipient you have identified is not a valid recipient of the specified 
     envelope."
      }

当另一个信封 ID 通过时。请注意，我们创建的信封将 ClientUserId 和 Email 设置为相同的值。我们使用将 UserName 设置为 GetRecipientsList 指定的值的技术（并且始终具有），但它仍然失败，因此这似乎与已经回答的类似问题不同。

    [Theory]
    [InlineData("redacted")]
    [InlineData("redacted")]
    public async Task ShouldCreateRecipientView(string envelopeId)
    {

        var accountId = await new DocuSignCredentials().GetDocuSignAccountIdAsync();

        var envelopesApi = new EnvelopesApi();
        var recipientList = await envelopesApi.ListRecipientsAsync(accountId, envelopeId);
        Assert.Single(recipientList.Signers);
        var signer = recipientList.Signers.First();

        var viewOptions = new RecipientViewRequest()
        {
            ReturnUrl = "http://localhost/return",
            ClientUserId = signer.Email,
            AuthenticationMethod = "password", 
            UserName = signer.Name,
            Email = signer.Email,
        };

        var viewUrl = await envelopesApi.CreateRecipientViewAsync(accountId, envelopeId, viewOptions);

    }

编辑：如果我们像下面这样设置 viewOptions，它仍然会以同样的方式失败。控制信封 ID 继续传递。

        var viewOptions = new RecipientViewRequest()
        {
            ReturnUrl = "http://localhost/return",
            AuthenticationMethod = "password", 


            ClientUserId = signer.ClientUserId,
            Email = signer.Email,
            UserId = signer.UserId,
            RecipientId = signer.RecipientId
        };

【问题讨论】：

标签： docusignapi

【解决方案1】：

您可以将 RecipientId 添加到 RecipientViewRequest 对象吗？并确保它与您在创建信封时使用的相匹配？这应该有助于识别系统正在寻找的收件人。

【讨论】：

我们在创建信封时不设置 RecipientId。让我们感到困惑的是，这个错误只发生在一个信封 id 上，而不是其他任何一个。就像 API 对信封中的收件人撒谎一样。我们已经完成了一些工作，并将其缩小到 ClientUserid ——如果我们传入 UserId 和 ClientUserId 对，那么“控制”信封 ID 仍然通过，但被测信封 ID 失败。如果我们传入 just UserId，那么两个信封 ID 都会通过。（但生成的嵌入式签名体验是只读的。）
每个收件人都有一个与之关联的收件人ID。如果您不知道它是什么，您可以通过调用 GET 来获取收件人的所有信息。
您必须通过 clientUserId 才能嵌入签名体验
是的，我们知道嵌入式签名体验需要 ClientUserId；我们正在尝试隔离 API 不喜欢的内容——它显然无法匹配这个特定有问题的 enveopeId 的 ClientUserId。另外，请参考上面的编辑——以最后一次编辑的方式构建视图请求选项应该是防弹的。
是的，现在看到了，您正在传递 RecipientId。您确定 RecipientId 、 UserName 和 Email 与信封上的内容相同吗？

【解决方案2】：

事实证明这是采用签名的 Docusign 错误。

为某些收件人创建一个信封
收件人签署一个字段，采用新的签名和全名，然后“稍后完成”
使用与第一个信封完全相同的寻址参数为同一收件人创建第二个信封
收件人在第二个信封上签名，这是关键部分，采用不同全名的第二个签名（虽然他们仍然可以看到第一个签名），然后再次“稍后完成”
收件人尝试打开第一个信封；嵌入式签名创建收件人视图现在将失败并显示“未知收件人”，因为信封中的收件人信息不反映附加到收件人用户 ID 的最新全名。

如果您的嵌入式签名代码可以找出采用的最新全名，并在创建收件人视图时将其用于 UserName 参数，那么它将起作用。但是由于授权限制，很难获得最新的全名。

我们正在使用的解决方法是通过在创建信封时为 ClientUserId 使用随机字符串来为每个信封强制一个新的 Docusign 用户 ID。不完全令人满意，因为用户签名体验不再是最佳的——他们必须接受每个信封上的“电子签名和记录”条款，并且他们将无法维护签名列表。而且它对所有破损的信封和我们已经创建的信封都没有帮助。

【讨论】：

【解决方案3】：

正如 kayjeta 所指出的，存在一个极端情况，涉及多个飞行中的信封和为同一个专属签名者采用的多个签名。最终结果是一个信封，其中 GetEnvelopeRecipients 调用返回的签名者名称与信封中的内容不匹配，从而导致对收件人令牌的请求失败。

要解决此问题，应用程序可以：

1) 使用创建信封时定义的原始名称发出收件人令牌请求

2) 获取 GetEnvelopeRecipients 调用的结果并将其插入到 UpdateEnvelopeRecipients 调用中以“重新同步”信封并使所有内容重新对齐。

已针对此行为提出产品问题。它在内部被跟踪为 EC-1965。

【讨论】：

【解决方案4】：

如果强制收件人尚未完成签名，则原始收件人信息将继续有效。如果他们已完成签名并且您希望在随后的某个时间点将它们返回到信封中，那么您将需要获取现在更新的名称并将其用于收件人视图 API，或者您可以获取 userId 并使用它代替姓名和电子邮件，用于“收件人视图”的所有后续使用。我推荐后一种方法，因为签名者对名称的更改不会影响分配的“userId”值。

【讨论】：