MAPI middleware - API implementation part 4

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:

1. Remote Operations (ROPs) that actually perform some business logic (check for emails, create folder, etc)

2. 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 Fast Transfer, Incremental Change Synchronization, Notification and Other 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.

In the previous challenge we did not do all the testing with Outlook since we did not have implementation of Fast Transfer and synchronization ROPs, and they are in scope of this challenge, so the final task is verifying the ROPs with the mock data store work with actual Outlook client. You should at a minimum verify the folder hierarchy and folder contents are synced and email can be sent and received. In case there are issues with implementation of previous ROPs or mock data store, fixing them is in scope, except if you discover that a lot of rework is needed to get them working with Outlook - in such case you have to raise the issue in the forums and document the issues in your submission.

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

• Postman collection to verify the endpoints and demo video

 

Final Submission Guidelines

See above