I put together some code for accessing CRM using the DLL's provided in the SDK download and tried out both the early binding approach and late binding approach.
What I'd like to do is in addition to having some custom entities that my users will access in Dynamics (through the Dynamics UI in the cloud), I also want to build some Android apps that talk to Dynamics.
My understanding is that I can talk to Dynamics from Android via REST (assuming I properly handle the authentication and getting tokens using ADAL libraries since my Dynamics instances run on the Microsoft cloud) or I can use the SDK with .NET as a middle-tier.
What's the recommended approach? Is there a best practice? When would I use the DLL's provided in the SDK and maybe wrap them in my own Web API vs. connecting to Dynamics directly via REST?
Please help this noob.
Kind of hard to say, depends on your talents and needs. Here is a great website link to get started though:
http://blogs.msdn.com/b/crminthefield/archive/2015/01/12/build-your-own-crm-mobile-app-s.aspx
Just a note on the Rest calls, you can only perform CRUD operations by default, and will need to jump through some hoops to perform the other calls.
Related
We must use C# MS bot in windows service. How to implement it in .Net core for MSBot SDKv4?
All samples using IIS/Azure App service as hosting platform.
They're aren't any examples or samples that show how to explicitly do this. But you should be able to follow articles such as this or this and then tweak as needed. It shouldn't be much different than hosting any other asp.net core application.
The two points to make sure and cover are:
Make sure that the bot/application is configured (whether in appsettings.json or otherwise) so that it has the right configuration data. Specifically appid/password
Ensure the endpoint can be hit by the connector/channels.
I have a project that is referencing an XRM Entity file and I was wondering if calling the API methods can completely replace my interaction with this file. E.g. there is a data contract between this XRM layer and CRM such that when an update happens in code through the XRM layer it will trigger the proper workflows in CRM. Will this interaction still be the case while interacting with the API?
Currently there are two active endpoints in CRM, the 2011 endpoints, and the WebApi endpoints (8.0, 8.1, 8.2, 9 etc). Previously, the SDK for CRM (Microsoft.Xrm.Sdk) has entirely been utilizing the 2011 endpoint via the IOrganizationService. There is a commitment to MS to replace the calls under the covers from the 2011 endpoint to the WebApi.
So if the desire is to use the WebApi and you're doing .net development, I'd just stick with it. If the idea is to remove all dependencies to the SDK, there is nothing stopping you as well. I would argue that you're going to have to spend more time ensuring you're handling all of the WebApi nuances correctly than any potential benefit you'd receive from removing dependencies on the SDK framework.
CRUD operations happening through CRM SDK Org Service or WEB API will trigger the configured WFs seamlessly as per Dynamics platform design.
The file you generated using crmsvcutil is helpful for Early bound coding which will help type check in compile time. Another way (without this file) is Late bound which is runtime check. Web api is going to be Late bound, so file can be retired and calls can be replaced.
If you are blocked with any particular web api call, you can reach out to community for help.
I am attempting to integrate a web site with Quickbooks Pro 2012 and would like to know what the recommended method is as I'm having a hard time getting information from the Intuit site.
Can I use QBFC13 with Quickbooks 2012 or do I have to use QBFC12?
Since this is a website, I think the correct method is to use Web Connector, although the web server could have direct access to the QuickBooks company file.
I'm been looking for a recent Web Connector sample (one that doesn't use Microsoft.Jet.OLEDB)
1. Can I use QBFC13 with Quickbooks 2012 or do I have to use QBFC12?
To my knowledge, all newer version of the SDK should work fine on older version of Quickbooks. I believe I read somewhere that they make an effort to keep it backwards compatible.
2. Since this is a website, I think the correct method is to use Web Connector, although the web server could have direct access to the QuickBooks company file.
I personally did not go with the webconnector route, because I needed real time comms. The webconnector will periodically "connect" to your website, and ask if it has any work for it to do. I personally created my own WCF Self Hosted service, which the website conencts to when needed. This wcf service, then interfaces with the quickbooks SDK, and passes the required info back to my website, when it wants it.
3. I'm been looking for a recent Web Connector sample (one that doesn't
use Microsoft.Jet.OLEDB)
Cant help you out here, although the QB specific stuff should generally still apply? Can't see why an example using a Jet DB would make the QB part of it unclear?
You can use either. You just need to make sure the QBXML version used is supported by QB.
Yes, you will need to use the web connector since this is going to a web site.
Good morning,
I am going to write a web service and I am not sure which framework would suit the situation best. I understand what Node and .Net are good at.
The client will call the services at the following stages:
App loads up - user logins in via Facebook API.
User can create an "entity". This entity will be stored in a database (SQL for .Net/ Azure table for Node) and also posted to a Facebook application (timeline stuff). User can make changes to this at any time.
User can browse Facebook Friends (Facebook API again).
Changes to the entity will be pushed to all users who have "joined" the same entity (SignalR .net/Socket.io Node).
That is the skeleton of the web services, there may be more Facebook calls or CRUD operations. Which Framework will handle this best?
Many thanks.
Aside from the mentioned WebAPI, also consider the excellent ServiceStack for building a webservice.
Any well-written code regardless of the framework will be able to handle it.
If you are a .NET developer I personally think type safety of C# is important so I would not go down the Azure node.js way since it will also force me to use Azure.
I would personally use ASP.NET Web API.
As long as you build your application on a solid framework, you'll be on the bright side (assuming you know how to set-up such an application in a secure and proper manner). For .NET i'd use the Web API and for node.js i'd stick with something like express/connect.
Just keep in mind that node.js and the frameworks based on it are still subject to heavy changes, whereas ASP.NET is production-safe since years.
As a bottom line, i don't think you're able to say "X is better than Y because of Z" in this scenario. It's a matter of personal preferences, infrastructure and your technical skills.
Is there any way through which I can exchange data between two organization.
I want to do my coding in Plugin only. Can we write a code in plugin by which it accesses/manipulates the data of a different org through web services only and not directly hitting its database.
In know the orgs are different worker groups. Just wanted to know if its possible or if there is any other technique.
Thanks in advance.
The data for each CRM organisation is exposed via web services which differ slightly for CRM 2011 and CRM 4. The best thing to do is download the latest version of the SDK for the target platform as there are several examples in there for plugins and service based operations.
From your plugin you will be able to access the other organisation via this service and a connection to the service for the "local organisation in which the plugin is running will be available from the IExecutionContext parameter passed to your plugin. Any operations you carry out across both orgs will not be transactional though.
Also be sure to take a look at the sync and async options available for the plugins. If their use is appropriate for your scenario consider using an async plugin for the updates to the target org to minimise their effect on the source org.
Plug-ins will work. Hitting the database directly is actually not a supported model anyways. You can also think of using BizTalk as the middleware.