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.
Related
I am trying to create an Event using Microsoft Graph SDK, as following the document #
https://learn.microsoft.com/en-us/graph/api/user-post-events?view=graph-rest-beta&tabs=csharp
1.Created "authProvider"
2.Created GraphClient with above AuthProvider
3.Creating Event using
The event is not creating also no exception/error is throwing, Could any one help me here?
This is happening because this call is being made with same transactionId frequently. It avoids unnecessary retries on the server.
It is an optional parameter , just comment out this property and try again. It should work.
Note : This identifier specified by a client app for the server , to avoid redundant POST operations in case of client retries to create the same event and also useful when low network connectivity causes the client to time out before receiving a response from the server for the client's prior create-event request.
More info is required here, as the reply from Allen Wu stated. without any details I would focus my efforts on the authprovider piece and azure app registration piece. as the rest of the example is just sending a post request to graph api.
but what is recommended really depends on what type of application you are trying to build. eg. is it a service daemon, a web app, mobile app, desktop app, single page app, etc.
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
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.
I am having trouble using Microsoft Face API. Below is my sample request:
curl -v -X POST "https://westus.api.cognitive.microsoft.com/face/v1.0/detect?returnFaceId=true&returnFaceLandmarks=false&returnFaceAttributes=age,gender" -H "Content-Type: application/json" -H "Ocp-Apim-Subscription-Key: 1xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxd" --data-ascii "{\"url\":\"http://www.mrbeantvseries.co.uk/bean3.jpg\"}"
I use the subscription id from my cognitive services account and I got below response:
{
"error": {
"code": "Unspecified",
"message": "Access denied due to invalid subscription key. Make sure you are subscribed to an API you are trying to call and provide the right key."
}
}
Not sure if I've missed out anything there. Can someone help me on this? Very much appreciated.
I ran into the same problem. I read the API documentation and it states the following.
You must use the same region in your REST API call as you used to obtain your subscription keys.
First, you must find the location of your subscription.
In order to find the location of your subscription region, you must go to Cognitive Services -> Properties under the Label Location, you will find your subscription region.
See below.
Second you must find the correct endpoint to make the call to.
For example, if I want to make a call to the Computer Vision API,
My location is East US, I will use either key 1 or 2, then I will use the following endpoint
East US - https://eastus.api.cognitive.microsoft.com/face/v1.0/detect
You will now be able to have access to the API.
It appears that you've entered your Azure subscription ID instead?
In the Azure portal, you can find the API key under 'Keys', shown below:
It will be a 32-digit hexadecimal number, no hyphens.
I had faced the same issue, it seems like there is some problem with the keys generated newly. To fix this you can actually add your endpoint as well, when you create the object for IFaceServiceClient. You can see the code below.
private readonly IFaceServiceClient faceServiceClient = new FaceServiceClient("your key", "Your endpoint");
CesarB is correct. You must create a Resource of Cognitive Service in Azure first and then get the subscription key from it.
the region is not always 'westus', it really depends on what region you select when you created the resource. You can also check it on the endpoint of overview of the Resource
I ran into a similar problem. I figure it might be helpful to some people, so I am posting it here. (btw Azure support points me to this post here)
I was trying to run through the sample file for ImageSearch of Azure. I was refering to these pages:
https://learn.microsoft.com/en-us/azure/cognitive-services/bing-image-search/quickstarts/csharp
https://learn.microsoft.com/en-us/azure/cognitive-services/bing-image-search/quickstarts/client-libraries?tabs=visualstudio&pivots=programming-language-csharp
https://github.com/Azure-Samples/cognitive-services-dotnet-sdk-samples/blob/master/BingSearchv7/BingImageSearch/quickstart/bing-image-search-quickstart-csharp.cs
I was receiving a mixture of 404 Not Found error & 401 unauthorized error when send requests to the Bing Search resource, using
Microsoft.Azure.CognitiveServices.Search.ImageSearch. I figure it must be something wrong with either my credentials or my endpoints.
After struggling with it for hours, reading through posts and talking to Azure support member, I finally find the problems:
The base Uri Endpoint I was assigned on the Azure Keys & Endpoints webpage is incomplete. (https://api.bing.microsoft.com/)
The base Uri Endpoint on the sample tutorial pages was outdated because of the 2020.10.30 transition between Cognitive Services to Bing Search Services. (https://api.cognitive.microsoft.com/bing/v7.0/images/search)
As of 2021.09.22, the correct global base Uri Endpoint for Bing Image Search is:
https://api.bing.microsoft.com/v7.0/images/search
Hope this would be helpful to anyone and save mankind some time.
Endpoint
https://westeurope.api.cognitive.microsoft.com/face/v1.0
Endpoint and the subscription key must be consistent.
look at Microsoft Overview for this info!
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.