From this official docusign support guide, I understood that we don't need to add Email or FirstName or LastName atrributes in CRL call when SigningGroup is used. My custom button url in salesforce is below.
/apex/dsfs__DocuSign_CreateEnvelope?DSEID=0&SourceID=a3G4C000000HE8X&
CRL=SigningGroup~LegalSigner;RoutingOrder~20;Role~Signer5
&OCO=Send
When I try to send a document, I get the following exception:
Error: System.CalloutException: Web service callout failed: WebService
returned a SOAP Fault: The email address for the recipient is invalid.
The recipient Id follows. faultcode=soap:Client
faultactor=https://demo.docusign.net/api/3.0/dsapi.asmx
The error says that the email address is invalid, because I did not pass one in the CRL parameter.
Anyone have an idea on what is wrong with my custom button url?
I talked to docusign professional service team today and guess what? We need to upgrade our docusign installed package version in the org. (upgraded from 6.3 to 6.7.2)
This document from docusign website says
Future updates will be downloaded and installed automatically.
Wondering why it never got upgraded automatically for us. While the error message is so mis-leading, please check your version package number before you start using any new functionality that is released. Lesson Learned.
Related
New to the forum :) - first post. I am trying to set up DocuSign in Salesforce for a client and keep running into an issue when trying to create an envelope template. Some context: my client has a DocuSign Business account (not Gen/ Negotiate), I have added the documents, and can add non-merge fields fine. The only issue is when I try to place the merge field, not create it, I receive an error:
Save Error: Some fields might be out of sync. Unable to connect to the service. Failed to connect to the salesforce service.
So far I have tried: adding IP addresses to Salesforce, removed MFA authentication for API, I have tried clearing cache and cookies, in different browsers, and in incognito mode - no success. I think I just have missed a step in set up? OR is this just not a feature of the client's current account and they need to enable the "Gen" feature to use merge fields?
Appreciate the help - I am also new to Salesforce administration and coding - so I am learning as I go and bear with me if I am not picking up all the "lingo" up front.
It sounds like you're using the legacy DocuSign for Salesforce package if you're not using Gen/Negotiate, so there are typically a couple of issues that could cause the error that you're seeing. The first is a caching issue, so you could try in an incognito browser or by clearing cache and cookies for the browser.
The other issue could be that the connection between DocuSign and Salesforce was broken and needs to be connected again. If that's the case, you could follow the steps in this article. If you're still running into problems, I'd advise to reach out to the DocuSign support team so that they can take a look with you (https://support.docusign.com/).
I used the labelling tool to train my model and successfully generated the modelID. When tried the "Get List Custom Models", successfully received the list of models I trained, but when tried to call the "Analyse Form" API, got the error message 404 "resource not found".
Also tried with the logic app - passed the modelID and the link as per specification:
https://something.cognitiveservices.azure.com/formrecognizer/v2.0-preview/custom/models/modelID/analyze
but again got the error 404. Any idea what might be wrong? Thanks.
Form Recognizer Logic App is currently using Form Recognizer v1.0 (preview) and models that were trained with v2.0 API or the labeling tool are not available via the Logic App Form Recognizer connector. When calling the API please call the v2.0 API using the same resource ID and key you used in the labeling tool project.
I am using IBM Watson Visual Recognition for a custom model. I have uploaded my dataset as .zip files, which is fine so far. However, I cannot train the model. When I go on my Watson services, it says:
Error fetching custom collections: Error in Watson Visual Recognition service: Recieved invalid status 403 in getAllCollections response for guid crn:v1:bluemix:public:watson-vision-combined:us-south:a/649b0335a5a44f6d80d1fd6909e466f9:8a71daa3-b0be-42ac-bb72-1473de835c19:: at endpoint https://gateway.watsonplatform.net/visual-recognition/api/
When I try to train the model, it says:
"Error in Watson Visual Recognition service: Request Entity Too Large"
To the best of my knowledge, I have checked Google and StackOverflow for solutions, but didn't find any. I am using the Lite version. I only have one project, and one Visual Recognition instance. Please note that it worked for a different Visual Recognition model before, but later I could not use or access that model. So I deleted the older, trained model and tried to create a new one with the above mentioned error.
Does anyone know a solution?
Thanks for your interest in Visual Recognition.
HTTP 403 is a standard HTTP status code communicated to clients by an HTTP server to indicate that access to the requested (valid) URL by the client is Forbidden for some reason. It indicates some problem with your account access.
The "Request Entity Too Large" is a bit misleading, it happens sometimes when the error should be a 403 on POST requests, like training.
As a lite plan user, you may have used up your free credits for the month, for example.
You should double check that you are providing the correct credentials, and check the usage dashboard of your IBM Cloud account, which is described here: https://cloud.ibm.com/docs/billing-usage?topic=billing-usage-viewingusage
If this does not resolve your problem, you can open a support request here https://www.ibm.com/cloud/support
We currently have ADFS 2.0 with hotfix 2 rollup installed and working properly as an identity provider for several external relying parties using SAML authentication. This week we attempted to add a new relying party, however, when a client presents the authentication request from the new party, ADFS simply returns an error page with a reference number and does not prompt the client for credentials.
I checked the server ADFS 2.0 event log for the reference number, but it is not present (searching the correlation id column). I enabled the ADFS trace log, re-executed the authentication attempt and this message was presented:
Failed to process the Web request because the request is not valid. Cannot get protocol message from HTTP query. The following errors occurred when trying to parse incoming HTTP request:
Microsoft.IdentityServer.Protocols.Saml.HttpSamlMessageException: MSIS7015: This request does not contain the expected protocol message or incorrect protocol parameters were found according to the HTTP SAML protocol bindings.
at Microsoft.IdentityServer.Web.HttpSamlMessageFactory.CreateMessage(HttpContext httpContext)
at Microsoft.IdentityServer.Web.FederationPassiveContext.EnsureCurrent(HttpContext context)
As the message indicates that the request is not well formed, I went ahead and ran the request through xmlsectool and validated it against the SAML protocol XSD (http://docs.oasis-open.org/security/saml/v2.0/saml-schema-protocol-2.0.xsd) and it came back clean:
C:\Users\ebennett\Desktop\xmlsectool-1.2.0>xmlsectool.bat --validateSchema --inFile metaauth_kld_request.xml --schemaDirectory . --verbose
INFO XmlSecTool - Reading XML document from file 'metaauth_kld_request.xml'
DEBUG XmlSecTool - Building DOM parser
DEBUG XmlSecTool - Parsing XML input stream
INFO XmlSecTool - XML document parsed and is well-formed.
DEBUG XmlSecTool - Building W3 XML Schema from file/directory 'C:\Users\ebennett\Desktop\xmlsectool-1.2.0\.'
DEBUG XmlSecTool - Schema validating XML document
INFO XmlSecTool - XML document is schema valid
So, I'm thinking that ADFS isn't playing full compliance with the SAML specification. To verify, I manually examined the submitted AuthnRequest, and discovered that our vendor is making use of the 'Extensions' element to embed their custom properties (which is valid, according to the SAML specification) (note: "ns33" below correctly namspaces "urn:oasis:names:tc:SAML:2.0:protocol" elsewhere in the request)
<ns33:Extensions>
<vendor_ns:fedId xmlns:vendor_ns="urn:vendor.name.here" name="fedId" value="http://idmfederation.vendorname.org"/>
</ns33:Extensions>
If I remove the previous element from the AuthnRequest and resubmit it to ADFS, everything goes swimmingly. And, in fact, I can leave the 'Extensions' container and simply edit out the vendor namespaced element, and ADFS succeeds.
Now, I guess I have 3 questions:
Why was the reference number not logged to the ADFS log? That really would have helped my early debugging efforts
Is it a known issue that ADFS's SAML handler cannot handle custom elements defined within the Extensions element, and if so, is there a way to add support (or at least not crash while handling it)? My vendor has offered to change the SAML AuthnRequest generated to omit that tag, but said that it 'may take some time'-- and we all know what that means...
Does anyone think that installing ADFS hotfix rollup 3 will address this situation? I didn't see anything in the doc to indicate the affirmative.
Thanks for your feedback.
When facing a MSIS7015 ADFS error, the best place to start would be enabling ADFS Tracing. Login to the ADFS server as admin and run the following command. If you have a very busy ADFS server, might be wise to do it when the server is not as busy.
C:\Windows\System32\> wevtutil sl “AD FS Tracing/Debug” /L:5
C:\Windows\System32\> eventvwr.msc
In Event Viewer select “Application and Services Logs”, right-click and select “View – Show Analytics and Debug Logs”
Go to AD FS Tracing – Debug, right-click and select “Enable Log” to start Trace Debugging.
Process your ADFS login / logout steps and when finished, go to the event viewer mmc find the sub tree AD FS Tracing – Debug, right-click and select “Disable Log” to stop Trace Debugging.
Look for EventID 49 - incoming AuthRequest - and verify values are not being sent with CAPs value. For example, in my case, it was I was receiving the following values: IsPassive='False', ForceAuthn='False'
In my case, to address the issue, all I needed to do was create incoming claim transformer rule - for the distinct endpoints.
Once the CAPs were transformed to lower case true and false, authentication started working.
I'm working on an integration scenario between SalesForce and BizTalk Server 2010. I have read the following blogs
http://seroter.wordpress.com/2009/10/11/orchestrating-the-cloud-part-ii-creating-and-consuming-a-salesforce-com-service-from-biztalk-server/
http://soa-thoughts.blogspot.com.au/2010/08/biztalk-salesforce-and-msmq-part-i.html
http://soa-thoughts.blogspot.com.au/2010/08/biztalk-salesforce-and-msmq-part-ii.html
I set the sessionId in a message assignment shape as described in the posts:
SfdcMessage(WCF.Headers) = "<headers><SessionHeader><sessionId>00DK0000005Du2o!AREAQLnrXpVFRAAgwT_Z7iaK0do1IltgHqDLyDfLhbkUGqvFMvzNURdgRtKdPc47cO9sZpOPJ0x8q496vQJsXKGrXt4BcdLW</sessionId></SessionHeader></headers>";
However when my send port calls the SalesForce custom web service I receive the following error
A message sent to adapter "WCF-BasicHttp" on send port "WcfSendPort_SP" with URI https://abc.xyz is suspended.
Error details: System.ServiceModel.FaultException: sf:INVALID_SESSION_IDINVALID_SESSION_ID: Invalid Session ID found in SessionHeader: Illegal Session
at Microsoft.BizTalk.Adapter.Wcf.Runtime.WcfClient`2.RequestCallback(IAsyncResult result)
I did some more research and came across these posts:
http://boards.developerforce.com/t5/General-Development/INVALID-SESSION-ID-Invalid-Session-ID-found-in-SessionHeader/td-p/74031
http://boards.developerforce.com/t5/Perl-PHP-Python-Ruby-Development/INVALID-SESSION-ID-Invalid-Session-ID-found-in-SessionHeader/td-p/66846
http://boards.developerforce.com/t5/General-Development/INVALID-SESSION-ID-Invalid-Session-ID-found-in-SessionHeader/td-p/200705
Has anyone encountered this issue?
Any help is appreciated.
Cheers,
A couple of thing in regards to this:
The blog posts I'm referring to in my question are too old so superfell is right in that the namespace needs to be added in the SessionHeader which is also mentioned here: http://boards.developerforce.com/t5/General-Development/INVALID-SESSION-ID-Invalid-Session-ID-found-in-SessionHeader/td-p/200705 "Your SessionHeader and sessionId elements in the soap header are not in any namespace, they need to be in the xml namesapce defined by the WSDL. The newer API endpoints are stricter about this."
A friend pointed me to the book "Microsoft BizTalk 2010: Line of Business Systems Integration" where the author writes: “Do not forget to put a namespace on the SessionHeader node as the Salesforce.com API is strict about this and will return an invalid token message if the namespace is missing.” In the book the correct format of the SOAP header is stated as:
SFDC_QueryRequest(WCF.Headers) = "<headers><SessionHeader xmlns='urn:enterprise.soap.sforce.com'><sessionId>" + Chapter10_SFDC.TokenManager.TokenManager.SessionId + "</sessionId></SessionHeader></headers>";
Basically I was missing the namesace xmlns='urn:enterprise.soap.sforce.com'.
Also when configuring your send port make sure to import the custom binding *_Custom.BindingInfo.xml and NOT the .BindingInfo.xml or else you will still have sessionId issues.
Cheers.