Error with Microsoft Graph API - Outlook Internal : Unexpected error Data Type mismatch in array

[kpb26]

I've been working on using the Microsoft Graph API - Outlook Web API available on the Digital Exchange, and I'm running into a problem.  I'm attempting to add an additional action "List Unread Messages from Inbox" that will return a list of all messages currently marked "Unread" in the Inbox of the provided ID.  I've put this in the URL Path: "/users/[ID]/mailFolders/Inbox/messages?$top=500&$filter=isRead ne true" and I get the following error:
"Internal : Unexpected error Data Type mismatch in array: Element 'False' has type instead of expected type 'System.String'"

It appears that this error is caused by the $top, as removing it also removes the error, but without it I only get 10 messages at a time.  I see in the Graph documentation that there is supposed to be a url returned in the odata.nextLink, and I see in the Common Code for the Blue Prism Web API that there is code that should return this, but I have been unable to determine how to access it.  Can someone help me get access to more than the top 10 messages in my inbox?

[ewilson]

Hi Kevin,

Have you tried testing your method with Microsoft's Graph Explorer utility? I just tried with this endpoint definition and it worked​:

https://graph.microsoft.com/v1.0/me/messages?$filter=isRead ne true&$top=2

Of course, this is running against my own mailbox. It looks like you're trying to read another users inbox. If you try it with Graph Explorer, and it doesn't work, it might be a permissions issue.

Cheers,
Eric

[kpb26]

Hey Eric,
  So, I just got done running some tests.  I added a parameter of "Count" and placed it in the call after top=.  When I pass in anything less than 15 with the ID for this process, I get back the results I expect (n number of unread messages), but once I change Count to 15, I get the error.  It appears to me that the error is in Blue Prism's handling of the results.  I also tested removing the Results parameter of "Messages" and just letting it return a JSON string in Response Content, this works even if I put 500 in for the count.  What's strange is that if I pass in my email address (we gave it permission while trying to get the Graph API working in the first place) it works with any number while returning results, so possibly there is something in the result content that is coming back with the other address?

[ewilson]

​Hi Kevin,

I'm not seeing the behavior you describe. I've changed the definition of the standard List Messages action to replicate what I think you're doing, and I'm getting back results. Can you post screen shots of you action definition?

Regarding NextLink, in all the other Graph connectors we include a common action called Get NextLink which you pass in the next link URL fragment you received from another action call (ex. List Messages). The Get NextLink action then pulls the results of that next page. Unfortunately, it seems that action wasn't added to the Outlook connector. I'll get that straightened out today.

Cheers,

[kpb26]

Thanks Eric.  Below are my pictures.  Again, it appears that the issue is in how Blue Prism handles the result set since I get different results from different mail boxes.

[ewilson]

Ah, I just got the error. So it's not really an issue with how Blue Prism handles the data per-se, but with how the underlying Newtonsoft library is trying to parse/convert the JSON into a DataTable that Blue Prism can then pass back to you as a Collection.

I'll have to research this a bit more.

Cheers,
Eric

[ewilson]

I think I figured out what's going on. In my mind, this is a bug in Graph, but there's probably no chance of getting this addressed.

What I'm seeing is an element within the JSON called isDeliveryReceiptRequested. In the majority of cases this elements value is set to null. However, there are random messages in my inbox where the value is set to false. The problem with this is that Newtonsoft defines the DataTable based on the contents of the very first record in the array, and it assumes every subsequent record will follow the same data type layout.

For Newtonsoft, null equates to an empty string value whereas a value of false (no quotes) equates to a boolean. So when Newtonsoft lays out the DataTable definition it sets the type of the column isDeliverReceiptRequested to System.String. When it hits a record with isDeliveryReceiptRequested set to false (or even true for that matter) it interprets that as a boolean and throws a type mismatch exception.

There are two ways this could be addressed. Ideally, Microsoft could fix Graph to always include false or true for isDeliveryReceiptRequested. If a field has a specific type of boolean (when populated), they shouldn't be placing a value of null in it. Alternatively, you could implement our own code to handle parsing the JSON response into a Collection instead of using the native Newtonsoft deserialization (which is what the Json Path setting is doing), catch any type exceptions, and handle them.

Cheers,

[ewilson]

BTW - I forgot to mention that we just uploaded and update to the Graph Outlook Web API component that includes the Get NextLink action.

Cheers,
Eric

[bruce.liu]

I have come across this limitation quite some time ago. I have summarised this in a slide deck below for your reference.