I'm trying to configure a WCF-WebHttp send port for accessing the Dynamics CRM OData REST WebAPI but I hit a road block getting the authentication behavior to work.
Configuring the endpoint Url, credentials and transport security the send port fails to process messages with the error
System.IO.IOException: Authentication failed because the remote party has closed the transport stream.
Following BizTalk 2013 to CRM 2011 Integration I tried to use the ClientCredential endpoint behavior but the problem stays the same.
I am aware that the problem is to retrieve the authentication token but I have not found any way to create an endpoint behavior being able to handle this.
I have a working WCF-Custom SP targeting the SOAP endpoint but I couldn't find any trace of the schema usually provided as part of the CRM SDK in v9.0.2.4 so I figured Microsoft is gently nudging us towards the new REST Web API instead.
The latest version of Dynamics CRM requires TLS 1.2 as per Microsoft Dynamics 365 Customer Engagement (online) to require TLS 1.2 for connectivity
To enable that you either
need to change your End Point Behaviour to tell it to use TLS 1.2 the same way that it was done for the Saleforce End Point Behaviour in this blog Salesforce disabling TLS 1.0 – How to get it working for API calls via BizTalk
or make sure that you have the correct CU installed as per Support for TLS 1.2 protocol in BizTalk Server and then follow the link from there to the article MS16-065: Description of the TLS/SSL protocol information disclosure vulnerability (CVE-2016-0149): May 10, 2016 which tells you to set the SchUseStrongCrypto registry key. Note: This second option is server wide and will make ALL connections try TSL 1.2 first.
Why not use OAuth 2.0 for this? Setting it up in BizTalk is easy if you base it on this SalesForce example.
Related
I would like to know what is the easiest method to getting user presence for a website that exists on a server? We are using a web based application in dotnetCore
Is there any benefit to using ucma vs ucwa vs something else when getting user presence?
Currently I am using Lync SDK
lyncClient = LyncClient.GetClient()
Contact usercontact = lyncClient.ContactManager.GetContactByUri("sip:" + email);
var userPresence = GetStatus(Convert.ToInt32(usercontact.GetContactInformation(ContactInformationType.Availability)));
but once I deploy the app to the server I get an error since there is no lync client installed on the server.
Is there a better way to do this without installing anything on a server?
The Lync Client SDK is basically a SDK that remotely controls the currently running instance of the Skype Client. (as you have found out) Not really useful for applications running on servers.
The options you have are:
UCWA - this is a web based API where you can log in as a user and query other users presence states, this will work with on-prem and on-line versions of SfB
UCMA - this is a C# based API where you create SIP endpoints (you can think of them as instances of a Skype client) that you can use to query other users presence states in two main modes, this mainly only works with on-prem SfB setups. It can work with SfB using on-prem federation to the SfB on-line users, but this still requires a on-prem SfB setup.
UCMA modes:
Client Platform - this basically allows you to create a SIP endpoint for a Skype user (i.e. you need a skype user login details to use)
Server Platform - this allows you can setup a "trusted application" that can use "trusted application endpoints" to do things like query for other user presence states. This does not require any user login details but is way more involved onsite application setup and is best for "server" installs.
Which one you use depends a lot on the details of what you want to do.
I have a ASP .NET Core MVC web service hosted in Azure to which I would like to POST data. I am able to post from Postman so I know the service is working and the required format of the request. I have another client sending what I believe to be the same post request but somewhere the request is failing. I would like to confirm the requests are reaching the service and if so see exactly what the request looks like when it gets there so I can compare to the working version. I have enabled web logs on the service but what info I can find as a result does not provide detail of the failed request. I also downloaded logs via the Cloud Explorer in Visual Studio but again I cannot see the content of the request to troubleshoot. I'm sure I'm not utilizing the logging fully but I'm not familiar enough with Azure web services to know what I'm missing and am having trouble finding guidance on the web. Perhaps it is not possible to capture the failed post data for security reasons? If so then presumably I need to hook up a debugger and see if I can step through the processing of the request.
What would be the most effective way to troubleshoot failed web service requests?
After further research I found an excellent reference on troubleshooting Azure Web Services at https://learn.microsoft.com/en-us/azure/app-service-web/web-sites-dotnet-troubleshoot-visual-studio. Using the information and tools covered there I was able to resolve my problem which ultimately proved to be a problem sending the request. Watching the web server logs it became clear the client's request was never reaching the server.
I am new to Solace MQ. My Question is,
How I can send request to Solace MQ from asp.net web application. What are the steps I need to performe to achieve this.
I have gone through the solace MQ Dev community and developer guide but it's not too clear for me. I want to understand the basic concept to send request to Solace MQ.
There's a step by step guide, with a sample application to send/receive a message over at http://dev.solacesystems.com/get-started/dotnet-tutorials/publish-subscribe_dotnet/
To summarize it, you will need to create and IContext, followed by an ISession. Then, use the ISession to send an IMessage.
Contexts act as containers in which Sessions are created and Session-related events can be handled. Sessions create a single connection to the Solace Appliance, and can be used for publishing.
Details on the Solace API concepts can be found at
http://dev.solacesystems.com/docs/core-concepts/
We have undertaken a project to make our DAM CMIS compliant and thus get connected with Adobe Drive using it's inbuilt CMIS connector. We will be following RESTful AtomPub binding of CMIS for this.
CMIS spec doesn't talk a lot about the authentication and seems like it is outside the scope of CMIS. I wanted to know how Adobe Drive client gets authenticated with any CMS/DAM using its CMIS connector. What is the mode of authentication used - is it HTTP basic, digest authentication or something custom. So I am not sure what would Adobe Drive send to get authenticated and what would it expect in the response. How do we pass back the session token that we will create.
Any pointers wrt this are appreciated.
Thanks!
http basic
Take a look at http://help.adobe.com/en_US/creativesuite/cs/adobedrive/CMIS_Connector_Tech_Note.pdf
Pages 6-7 show what you'd get in a valid connection response.
We have an intranet system that schedules routine tasks. We also have Fogbugz for bug tracking. When an urgent bug comes in, we track that task in the bugtracker. However, I need to write back to both the Intranet and our CMS. I'm thinking Biztalk as the middle piece, but am not sure the best way to go about it. Database adapter? Web services?
I know I can use the CMS adapter for Microsoft CMS. I'd love to hear your experiences with Fogbugz.
I'm guessing that watching the database for changes would be the best way to do it. That way, you could post any changes you saw happen in the FogBugz database through other Biztalk adapters.
Please keep us updated with what you decide to do - I'd be interested to hear about it.
Version 6 of the FogBugz API is pretty well documented at http://www.fogcreek.com/FogBugz/docs/60/topics/advanced/API.html. The API is implemented as an ASP page that accepts GET or POST params and returns XML after a user has been authenticated.
So, we can use the HTTP Send Adapter to POST requests to the FogBugz system, either updating bug records or retrieving information. The response from the API call is basic Xml that will be returned in the response body that can be read by BizTalk as necessary.
Be aware that the HTTP Send Adapter can only POST data - it cannot use the GET verb (http://msdn.microsoft.com/en-us/library/aa561642.aspx)
Isn't FogBugz based on a SQL Server Database? Or do you use a hosted alternative?
If it's using a SQL Server you're controlling I'd just tie up two send ports to the process that read and handles the "FixBugMessage". One send port that uses the CMS Adapter and writes to the CMS and another that just uses the SQL Adapter and via an Stored Procedure writes to the FogBugz database.