What are service end points in MSCRM 2011? - dynamics-crm

Tech Friends,
What are service end points in MSCRM 2011?
When I open a solution in MSCRM 2011, I see a separate a separate feature in left panel which is named as "Service end points". I did not find much documentation about the same and also how do we add new service end points?

Name endpoint comes from Enterprise Integration Patterns. You can work with CRM through user interface it provides for you, but there is other option. Your own software is able to interact with CRM, as with service. Interaction goes through the messages, your client software sends to CRM services. So, in this case both, software you are working on and CRM will have endpoints. Your software will have client endpoints, but CRM will have server endpoints. I don't think you need to add new endpoints in CRM, because there are already defined. Just use them sending messages from your code.

The above answer seems to be helpful but here is the response in MSDN Forums which says the endpoints are required for integration with Windows Azure.
Link:
http://social.msdn.microsoft.com/Forums/en-US/crmdevelopment/thread/5fa85ef2-1f6e-44f6-9752-dea120f9d9d0

Related

How to get Microsoft Dynamics CRM root service address?

I was reading the documentation and stuck in a problem that I do not know how to get Dynamics resource for acquiring access_token using any API (I know my CRM root service address but I do not want to hard-code this service name in my code base). Could you please provide me with the solution to this problem?
You need not to hard code it in code base like showed in documentation sample. But normally we will keep this in web.config or app.config xml file just like any connection string & consume it.
Use connection strings in XRM tooling to connect to Common Data Service for Apps
You can use the Online Management API to get a list of all the Dynamics 365 instances in your Office 365 tenant. I believe this is what the Plugin Registration tool does when you check "Display a list of the Organization(s)".
This looks useful:
https://learn.microsoft.com/en-us/dynamics365/customer-engagement/developer/online-management-api/sample-quick-start
The C# sample demonstrates how to authenticate to the Online Management API and then retrieve all Customer Engagement instances from your Office 365 tenant.

Is it possible to replace all XRM calls with Dynamics 365 Customer Engagement Web API?

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.

ManageEntitlementState workflow in Dynamics 365 version 9

Since Dynamics 365 version 9 upgrade, we have observed new workflows automatically created on CRM instance namely- ManageContractLineState, ManageContractState, ManageEntitlementState.
As I can see from the ManageEntitlementState workflow, it is to handle the status of entitlements in CRM. But earlier this was not done using CRM workflows.
Now each workflow instance will be running for each entitlement in our system which is a huge problem since it puts unnecessary load on our machine.
Is anyone else able to see these workflows on their instances? And why is MS adding these workflows?
October 2018 Release notes talks about deeper integration of entitlements between D365 offerings namely Field service & Sales (work order). There may be background automations happening to achieve this & Workflow is part of it.
Entitlement management
With this release, the Field Service application includes the ability to define entitlements and associate
them with work orders in field service scenarios. Entitlements help
service agents understand the service terms that customers are
eligible for.
This capability helps service organizations ensure
customers receive the appropriate on-site support that aligns with
their allowed entitlements, and that customers are charged according
to their negotiated terms.

PowerApps Common Data Service (CDS) 2.0 connector doesn't work for a Dynamics 365 CE instance

Hopefully, someone can straight up my PowerApps connectors understanding. Apparently, I have 3 connection options.
Common data service - this connection type only allows me to connect to CDS 1.0 databases, but I want to connect to an existing D365 v9 instance.
Common data service (experimental) - this connection type asked me for a D365 v9 instance ID, but everything is grey out after the step, i.e. it didn't show me any entity after connecting successfully.
D365 data source - this one works but I was told MS has stopped working on this connector. Also, I will have to update the connection after deployment to a different environment manually.
What is the best practice if I want to use a CDS connector? Or I will be stuck with the old D365 connector for now?
Thanks.
==11/1/2018 update==
I have a better understanding of my situation now. Every Dynamics 365 CE instance should have a PowerApp environment automatically, but one of my D365CE instances doesn't. I am suspecting it is because the D365CE instance is still version 8.2.
My question above is because I created an empty PowerApp environment and tried to connect it to the D365CE instance (v8.2). I will give you guys another update after I upgrade the instance to v9.
==11/30/2018 update==
Confirmed. By upgrading a D365CE instance from v8.2 to v9.0, the Power Platform generates an environment automatically and linked it to the D365CE/CDS.
Here's a breakdown of the three connectors you're looking at :
Common Data Service - this connector actually supports both versions of CDS, but it will be dependent based on the environment that you're in. So if you're in an environment that has a CDS1.0 database, it will connect by default to that environment. If you have a CDS2.0 database, it will connect by default to that environment.
Experimental Connector - this is similar to the previous connector, but it includes experimental features in development by our team, and isn't recommended for production use. Generally you should only be using this connector if there is a specific feature we announce in the experimental connector you wish you use.
Dynamics 365 Connector - this is similar to the base CDS connector, however it can only connect to CDS2.0 environments. It also has the ability to connect across environments. So you can be in Env1, but connect to a database in Env2. The normal CDS connector will only connect to the database within the environment you are building your app in.
Which one should you use? The Common Data Service connector is going to be your best option, it's where the most improvements are being released at the moment, and is designed to work best with PowerApps and Flow.
To connect to your Dynamics 365 environment, you'll want to make sure you start from web.powerapps.com and select that environment from the drop down in the top right, if you can't find your Dynamics 365 V9 environment - make sure you have system customizer permissions - if you do and you still can't see it, it may be an issue on our end. You can send me a message with your Dynamics org URL and we can check it for you.
Once you can select it from the environment drop down, you can then create a new app and use the Common Data Service connector, and it will connect directly to your Dynamics 365 data.
Hope this helps,
Clay.
I don't have much experience with CDS 1.0 in the Power Platform. I can share some insights on my experience with Microsoft Flow / Logic Apps, CDS 2.0, and Data Integration. So I hopes this helps add another perspective to this question too.
What is your goal in using Common Data Service? Just to pull Dynamics 365 CE data into it?
This recent Product Team Blog could be useful here if so.
Some initial feedback, if the main goal is to connect to a Dynamics 365 CE instance, consider using the Dynamics 365 Connector through Microsoft Flow. You can create a small Flow at https://flow.microsoft.com/ with a 2 step process like mine below. An event takes place in Dynamics, like creating an account. The event and it's data is captured and in used in a response process, like sending an email alert. In this case the alert is sent to the signed in users email.
From a developer standpoint you can also use the Xrm SDK and Web API to collect data and do some data processing as well in C# or JavaScript respectively too. This is more involved, but provides a greater amount of control around the data you're working with. There's a great intro to
Lastly you can spin up a PowerApp to surface your data as well with some pre build templates https://create.powerapps.com/.
Start with your Data and create a Dynamics 365 app in a phone layout.
Choose your organization and table.
After the app creates, hit play to run it.
Search for an account
It turned out the problem is not with the connectors but with PowerApp environments. By upgrading a D365CE instance from v8.2 to v9.0, the Power Platform generates an environment automatically and linked it to the D365CE/CDS. So, it should just work for all v9+ instances.

Exchange 2016 on-premise application access

I have implemented an application which accesses calendars in an Office 356 E3 tenant. I've used the client_credentials flow and obtained Admin Consent. So far everything seems to work as expected.
Now I have a customer how wants to use my application with an Exchange 2016 on-premise setup. Is there a way to use the same application in this setup as well? Or do I have to implement a new application using EWS?
The graph API is not available on on-prem Exchange, so yes, you have to replace the graph API code with EWS code.
Depending on your use case, it is probably possible to abstract it such that your application can use either one or the other.
We had a similar issue.
You can change from Office365 Api to the MsGraph Api which supports many of the same features as the Office365 Api does. Your on premise customer needs to put his Exchange servers into hybrit mode for this. MS explained the necessary steps here.
The only problem we had is that you cant subscribe onto on premise calendars.
Here is the MsGraph Api doc
https://learn.microsoft.com/en-us/graph/api/overview?view=graph-rest-1.0
You can also consider switching from Office365 to MsGraph entirely as this should also work for you Office365 customers. As I understand it MS is gonna expand the MsGraph Api in the future giving us a single point of contact for interaction with the Office suite and authentication.
#Marc LaFleur pls correct me if I'm wrong on this

Resources