I am using MS graph API to create an event in a user's outlook calendar. This event has attendees and contains some metadata that I added. When the invites are created for the attendees, the graph API calls my webhook for the newly created events for the attendees. However, those invites do not contain the metadata.
Is there a way to have the metadata in the initial event propagated to all other invites?
If not, is there a property that I can use that is copied over on to all invites??
Thanks
For the above scenario, you can use either extended properties or open extensions. Let me add few additional info about them.
(1) Extended properties - Use extended properties only if you need to access custom data for Outlook MAPI properties that are not already exposed in the Microsoft Graph API metadata
(2) Open extensions - In most common scenarios, you should be able to use open extensions - also known as openTypeExtension, formerly known as Office 365 data extensions - to store and access custom data for resource instances in a user's mailbox;
So check it out and see which suits your scenario. For more info, please refer.
Related
I've been integrating Firebase for a clients back-end dashboard system and I'm generating timestamps on activities which for FINRA/SEC purposes they would like to see set immutable.
Users have zero control over the data, all of it is handled by API calls to Node but through Node, the server is given full access permissions. Does Firebase provide a way to create a collection so that not even Node nor the Web UI can make changes to the info? Similar in the way an S3 vault-lock works.
I'm trying to extract the share permissions for a Calendar through Microsoft Graph (or even the old Outlook REST API) but it seems that there is no Graph endpoint to get a calendar's sharing permissions.
When fetching a calendar's details, the closest I found was isShared on the Calendar resource - but that doesn't give me the full data I see from the Web UI:
Basically, trying to receive the equivalent of Google Calendar's ACL list.
Am I missing anything?
Since you cannot share the calendar through the graph api, or open a calendar from some other user that they shared with you, there is no point in showing the ACL.
You might have better luck using the Exchange Web Service (or EWS) they do have those properties on folders. https://learn.microsoft.com/en-us/exchange/client-developer/exchange-web-services/folders-and-items-in-ews-in-exchange
Or if you really need it in the graph api (since the EWS is no longer the recommended way to talk to Office 365) you can create a ticket on UserVoice (if it doesn't exist already).
I have found some, but not all, pieces of the puzzle.
Using Graph APIs, when a user selects a document in my own web application, I can:-
Create a new temporary folder in their OneDrive account
Upload my.docx file to this location
Get the url for my.docx
Open the URL in a new tab, loading Office 365's MSWord editor (or viewer and editor after one more click)
This is where it gets a bit trickier. How can I get the edited content back into the location where my web application historically stored these documents?
Theorising, I can:-
Create a webhook subscription to the new folder I create
Implement a webhook listener (and validation) service
When the listener receives an 'update' notice for the document:-
Call the download(content) API, or from the driveItem metadata, download it from #microsoft.graph.downloadUrl
Persist it to my desired location within my web application
To me this sounds like it'll suffer from big delays. The webhook subscriptions typically send batches of changes and the frequency looks uncertain. It certainly wouldn't be great for versioning every individual save operation during the editing session.
Have I missed some more obvious path to Word as a Service? i.e. another API or a mixture of APIs?
Alternatives I've considered but haven't yet scoped: implement WOPI or WebDav within my own web application.
It sounds like you're only using OneDrive to take advantage of its built-in support for the MS-WOPI protocol. WOPI is basically an enhanced WebDav interface that is used by Office to work with remote document (i.e. files stored on OneDrive, Box, DropBox, etc.).
Your solution is generally fine and it is certainly easy enough to orchestrate. You can absolutely use webhooks to subscribe to changes to the file. You'll likely want some mechanism in your app to notify your system when they're "done" so you can clean up the file afterwards.
If you want a more robust solution, you'll need to look at WOPI. Implementing WOPI would allow you to keep these files on your system permanently. Office Online would use the WOPI interface to speak with your storage system and open/save/edit files in-place.
Keep in mind that implementing WOPI (or any protocol for that matter) is often a non-trivial endeavor. You will also need to get your final solution validated and whitelisted by Office before it can be used. Details on this process and how to request access can be found at the Microsoft Cloud Storage Provider Program website.
Today OneNote and Excel are the only office "document clients" that have API's exposed via a REST API publicly available in the Microsoft Graph.
The only other "publicly available options" I'm aware of are:
WOPI APIs, that kind of act like a REST API but muche older
The office add-in model (hosted in a client) with the JavaScript API
The word object library (old, relying on dcoms and needs to have office installed and licensed on the machine)
I am working on developing an integration with Workday. Under my initial analysis, I found that Workday provides multiple wsdls for different modules like "Human resource", "Inventory" etc. I can see this complete list at https://community.workday.com/sites/default/files/file-hosting/productionapi/operations/index.html
I am trying to understand how I get get this list progamatically in my integration so that my user can select one of the wsdls rather than typing in the full name of WSDL. Please share your thoughts on this.
You can programatically retrieve a list of all web service operations by creating a Custom Report based on the "Public Web Services" data source. The report can then be exposed as a RESTful WS for easy retrieval.
Some fields you can include in the report are: Web service, supported operations, api version, endpoint url, WSDL url, etc, etc.
This is highly customisable, in the sense that you can query the RESTful WS Report for specific versions, specific operations, etc, via Prompts / URL Params.
The report-as-a-service, supports also a variety of output formats as well as its own WSDL.
The purpose of a SOAP WSDL is to generate a client stub, i.e. a model that lets your client interact with objects exposed or consumed by the service provider. You don't interact with a WSDL at runtime - you interact with the stub. If you want to make multiple services available, you have to include each WSDL in your client application at compile time and generate their stubs. The services in a given API version do not change, so there isn't a reason to do this dynamically.
To add to the query asked, what we are trying to understand is that whether there an API call/request which we could hit to get the list of web services available to populate it on the UI to select from it.
For Example: In this link, https://community.workday.com/sites/default/files/file-hosting/productionapi/index.html, we have Absence_Management, Academic_Advising, Academic_Foundation and so on and Now, if I want it to be displayed to the end user so that He can select the webservice to be used and accordingly we could download the WSDL as to work on it.
When you view document folders in a SharePoint online site you have the ability to configure email alerts on folders based on when items are added or deleted. Can I do the same thing via the Microsoft Graph API? If this is not possible now, is there any plan to add this to the API in the near future? The only workaround I have been able to come up with involves using the Delta API to poll for changes periodically, but that requires a lot of processing as the Delta API is not very granular.
You do this using webhooks and registering a subscription against the resource you want to monitor.
See Using webhooks to receive service-to-service notifications for details and examples of how this works.