Question

此问题并不常见，我无法看到此请求与我们的其他任何请求有何不同。我通过PHP API发送了类似的请求：

<ns1:RequestRecipientToken>
  <ns1:EnvelopeID>...</ns1:EnvelopeID>
  <ns1:ClientUserID>1</ns1:ClientUserID>
  <ns1:Username>Jeff...</ns1:Username>
  <ns1:Email>jeff@...</ns1:Email>
  <ns1:AuthenticationAssertion>
    <ns1:AssertionID>(guid)</ns1:AssertionID>
    <ns1:AuthenticationInstant>2013-08-16T00:00:00.00</ns1:AuthenticationInstant>
    <ns1:AuthenticationMethod>Password</ns1:AuthenticationMethod>
    <ns1:SecurityDomain>MyDomain</ns1:SecurityDomain>
  </ns1:AuthenticationAssertion>
  <ns1:ClientURLs>...</ns1:ClientURLs>
</ns1:RequestRecipientToken>

然后回到这个

<soap:Body>
<soap:Fault>
  <faultcode>soap:Client</faultcode>
  <faultstring>The recipient you have identified is not a valid recipient of the specified envelope. </faultstring>
  <faultactor>https://www.docusign.net/api/3.0/api.asmx</faultactor>
  <detail>
    <ErrorCode xmlns="missing in Web.Config">123</ErrorCode>
    <ErrorReason xmlns="missing in Web.Config">The recipient you have identified is not a valid recipient of the specified envelope.</ErrorReason>
  </detail>
</soap:Fault>

就像我说的那样，我们的文档创建和签名通常都有效，所以如果有任何不常见的用户工作流导致我们不知道，或者如果有错误，如果有其他人有最近遇到了这个问题。感谢。

我排除了原因： 1）我登录docusign网站找到信封，并确保一切都在那里并匹配 2）收件人姓名，电子邮件和ClientUserId匹配，因为我使用了在执行RequestRecipientToken呼叫之前立即检索收件人信息的策略。

顺便说一句，我不认为Docusign应该使用Stack Overflow作为支持论坛，但它们是。

Answer 1

首先想到的可能性是：

信封已无效。
信封已过期。
收件人确实不是该信封的收件人。

您遇到这些零星错误的任何信封是否曾被取消或过期？当你收到这个错误时会发生什么，你是否只是在之后再次进行同样的确切调用，这次它有效吗？我首先确认这样的基础知识。 123的错误代码对我来说也是可疑的 - 以前没见过，我想知道这是否来自DocuSign平台。

对于上面列出的第三个潜在原因，您是否肯定您始终引用正确的电子邮件，用户名和clientUserId组合来正确识别收件人？如果其中任何一个与将收件人添加到信封中的时间不完全相同，那么您将收到该错误。

Answer 2

问题的原因是收件人名称与请求不匹配，并且仅对具有特定字符的名称发生。

您可以通过两个字段标识请求中的收件人：用户名和电子邮件。电子邮件匹配，但如果将名称存储在数据库中，则很容易无意中丢失一些特殊字符。一个简单的例子是姓氏O＆＃39; Brien，但也可能因名称中的非ascii字符而发生。

解决方案是不再使用从数据库中检索的名称发送RequestRecipientToken请求。相反，首先通过信封ID通过API请求信封，信封ID返回收件人列表，包括他们的姓名和电子邮件。通过匹配除电子邮件等名称之外的其他字段来选择正确的收件人。使用信封详细信息中定义的此收件人的名称作为RequestRecipientToken请求中指定的名称。

RequestRecipientToken偶发错误代码123的原因？

2 个答案: