Genii Weblog
Nitty-gritty details: Salesforce data to Notes example
Thu 26 Mar 2020, 03:47 PM
Tweetby 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.
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:
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:
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.
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:
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: