Challenge Overview
Challenge Overview
Welcome to the MAPI middleware API challenge. Our goal here is to implement Remote MAPI operations that would read and write the resources (ex emails, contacts, etc) from a custom data source instead of Exchange data sources like an outlook email inbox.
Project Overview
The project goal is to create EWS and MAPI middlewares and use them to provide access from Outlook to data from non-Microsoft apps/data sources. Integrating with those data sources is out of scope for this project - we will use static/demo data for verification only. EWS API is already implemented. This challenge will only implement a subset of ROPs.
Technology Stack
-
Typescript
-
Loopback 4
-
MAPI
Assets
See forums for access to the project repository.
Individual requirements
The goal here is to implement MAPI HTTP API that reads some static data, point Outlook client to that API and get the communication working between them. Here is a system diagram of what we’re trying to do
MAPI protocol is fairly low level (lots of bit fiddling) and consists of two important segments:
-
Remote Operations (ROPs) that actually perform some business logic (check for emails, create folder, etc)
-
MAPI HTTP endpoints - a wrapper protocol around ROPs that allows calling the ROPs over HTTP
In a previous challenges we have implemented the MAPI HTTP endpoints and ROPs for folder, message, transport and table operations.
See this link for the complete MAPI HTTP specification (note that this is just for reference - mapi http endpoints have been implemented in the previous challenge). See section #2 for endpoint details.
Note that the MAPI HTTP protocol is stateful - needs to keep track of open connections (for connect, execute, disconnect flow). “Execute” operation is the one that calls individual ROPs.
ROPs are specified in a separate document. In this challenge we only want to implement Property, Stream, Permission and Rule ROPs. Since there is no business logic to implement (we’re not integrating with external services yet), most of the endpoints should be straightforward to implement. We have an in-memory data store that is used to save/read data for ROP operations. Extend the same data store for the requests in scope for this challenge. Unit tests should be implemented for new operations and models - follow the existing structure in tests directory.
As a helpful resource, you can use Interop Test suites to test your protocol implementation - it should be useful for detecting implementation bugs, but your implementation doesn’t need to pass all the tests (since we are using mock responses and in-memory data store, not all tests scenarios can be handled).
NOTE: some of the property ROPs are already implemented, but make sure you integrate all of them with the data store in this challenge.
What to submit
-
Submit the updated codebase
-
README document with deployment and verification steps