Ben Langhinrichs

Photograph of Ben Langhinrichs

E-mail address - Ben Langhinrichs







Recent posts

Tue 19 May 2020

An unladen user



Thu 7 May 2020

Can we get a huzzah for updated Domino Limits?



Wed 29 Apr 2020

A bigger boat: when in Rome


July, 2020
SMTWTFS
   01 02 03 04
05 06 07 08 09 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31

Search the weblog





























Genii Weblog

Nitty-gritty details: Salesforce data to Notes example

Thu 26 Mar 2020, 03:47 PM



by Ben Langhinrichs
Yesterday, in my post From REST to Notes db in two seconds, I showed how you could pull data from a REST API and create an "instant" database. But, of course, the devil is in the details, and not all formats work particularly well. I have a special interest in Salesforce as a lot of friends have started to work for them or with the software, so I decided to show how some sample Salesforce data including custom fields would translate.
 
I should note, these demos are currently done in LotusScript with the Midas LSX in an unreleased version. We are building them into Exciton Power for Node.js. Both should be available in a matter of weeks, and any feedback would be greatly appreciated.
 
First, the data itself. Assume that the following was pulled in a query from a Salesforce REST API. It is only one of the records, but they all look like this.
 
Inline JPEG image
 
There are a number of default choices we make for you. There is a display title which is different than the Notes item sometimes, which is yet again different than the JSON value. For example, the "attributes" value is a JSON object, so how should we save it? How should we display it in Notes? Here are a few of the rules we follow:
 
1) For the "attributes"  object, we save two separate internal items:  attributes.type with the value "Merchandise__c", and  attributes.url with the value "/services/data/v20.0/sobjects/Merchandise__c/a00D0000008oWP8IAM". That looks like this:
Inline JPEG image
 
 
2) On the form, we skip object items called "type" even though we save them in the document. We include an editable text field called attributes.url, but we use the name Attributes (url)as the prompt. That looks like:
Inline JPEG image
 
3) In the view, we skip the objects entirely. Thus, the Id is the first column shown, even though the  attributes.url item exists on the documents. 
Inline JPEG image
 
While we are looking at the view, note that the "OwnerId" item has a title Owner Id of but is saved as an item called OwnerId. We use the capitalization to add spacing here if it appears to be proper-cased. Another thing to note is that "Price__c" item has a title of Price but is saved under the name Price__c. We recognize that Salesforce adds those suffixes, and we keep them for data purposes but don't see a need to display them. 
 
4) Another thing to note is that a boolean (true/false) value such as "IsDeleted": true is saved as text "true", In the view, it is centered, and on the form, it shows as a radio button:
 
Inline JPEG image
 
There are many other small assumptions we make, some of which can be overridden with properties, but we are not done. We haven't entirely decided whether presumed date fields should be stored as such (probably), and whether we should be able to handle other special cases like the Salesforce suffix (maybe). The more examples we try, the more we learn and tweak.
 
If you have a REST API data source you use regularly or would be interested in using, let us know and we can see how well it fits.

Copyright 2020 Genii Software Ltd.

What has been said:

No documents found