MAPI middleware - API implementation part 2

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

 

NOTE: Outlook integration only works on Windows - you will need Outlook client on Windows to work on this challenge

 

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 challenge we have implemented the MAPI HTTP endpoints and a few demo ROPs.

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 Folder, Message, Transport and Table 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. Implement a data store in memory that the endpoints will read/write data to - this is to showcase that Outlook works with the implemented operations(for example creating/deleting a folder should work in outlook). Similar data store is implemented in EWS service, you can use that as a reference (no need to use the same data store as EWS, we will integrate them later on).

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).

 

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