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
Related
I am integrating my SAAS application to Microsoft Teams. Right now integrated as Tab in teams. I am using my own API endpoint to authenticate and authorize the user. I have got some specific information about the user I am getting from API. How can I store it in Team context? Right now I used local storage in the web app. In Teams web app it seems working but I don't think it is working in Desktop app. Is there some API available in teams which helps to maintain the user state with Tabs? similar to userstate in Bots? Please help.
I would think local storage would be troublesome across devices anyway, perhaps consider server-side storage instead.
i'm quite new to Logic Apps. I got the task to make an auto reply function within Logic Apps that integrates with Exchange Online. Now I already performed this task using Outlook, but I have to be able to apply it to multiple mailboxes or even the entire company using Exchange. I'm about to get access to the Exchange Admin Center soon, but I don't really know how to start due to the fact that there is no simple way to make a connection to Exchange using Logic Apps. After some research, I think it's necessary for me to somehow make use of a REST API (I also read about the use of Exchange Web Services) to get the information I need, but my knowledge about this is quite small. I guess I'm gonna have to use a program like Postman to request information, so that I can start creating Custom Connectors to Exchange. If anybody has some understanding about this, feel free to reply and help me out! I will forever be gratefull!
There are several different approaches you could take to this if you (or probably they in your case) want your logic app to do all the work then you should use the Graph API rather then EWS (while its possible because its older API you'll loose marks on your assignment) have a look at http://martink.me/articles/using-microsoft-graph-in-logic-apps which covers the basics of what to do. To Get access to mailboxes tenant wide then you need to assigned Application Permission and get certificate (and store that in the KeyVault on Azure etc).
You can do this using Inbox Rules https://learn.microsoft.com/en-us/graph/api/mailfolder-post-messagerules?view=graph-rest-1.0&tabs=http and the Exchange Server will do all the work when it comes to doing the Auto-response (and has loop detection logic already) and your logic app then just need to do the Creation and management of the Rules.
But I would suggest you clarify with the person who assigned you the task whether they want the logic app to do the response (eg using the Graph API) or if its okay for the Exchange Server to do this for then (which should be more reliable).
You can also create Rules via the Exchange Admin Center and you could probably also through in Power Automate into the mix to do Autoresponse's so I'd clarify what they want so you don't waste time building something they don't want.
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.
We are trying to integrate our app with MS Exchange. One of possible features of that integration is to let other apps know if our app user currently performing some important work, so other users should see him as busy.
All APIs I found allow to get user free/busy status, but not set. Is there public api for a writing side?
The free/busy time option on Microsoft Exchange is generated from the Outlook/Exchange Calendar entries from the users. These infos are fetched from the users calendar by the Availability service as written by Microsoft here. So if you wish to "SET" something, you need to create an calendar entry for the user. If you try to add something to the backend environment which is managed by Microsoft Exchange you might cause issues for the users as they do not see that in there calendars. That is also the reason why you are unable to find a "free/busy time writing API". So please create a calendar entry for your purpose and let the MS Exchange Availability service do the rest.
A good starting point to understand the construct is:
Availability service in Exchange 2013
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