I'm fond of XML especially XSLT and the related XPath query possibilities.
Moving into the wonderworld of JSON I'm missing those platform independent query and rendering options.
For templating Mustache comes close, especially in regards of platform support, but XPath still has to find its match in the JSON world.

The closest equivalent is JSONPath (also available for Java ) with a nice interactive playground.

I was looking at adopting it for one of my projects written in vert.x.
JSON isn't native to Java and there are several competing implementations around JSON: Google's GSON, Jackson
and vert.x core JsonObject (there are probably more).

So I was wondering: What if I could use XPath and by extension XSLT directly on JSON? The first step there would be a save way to transform JSON to XML and back.
Using vert.x JsonObject and JsonArray as starting point,
I had the following considerations:

• I can't use XML tags to map to JSON labels, since labels can contain any character, XML tags are restricted
• The resulting XML only needs 2 elements: Element and Array
• An element can have a scalar value, my first test deals with strings only, or can contain another element or array
• An array does not have a value. It can contain zero or more scalar values and/or zero or more arrays or elements

So I build a small prototype. A simple class that reads a json file from the command line, prints it to the console, transforms it to XML, prints it to the console, transforms it back and prints it again.
The prototype depends on vert.x core.

The result can be found in this gist or read more.

The challenge

Salesforce canvas offers a capable integration point between Salesforce and external applications to surface them inside the Salesforce UI. One of the aspects is establishing identity. There are two options: OAuth and a signed request. I’m looking at the later. A signed request posts (as in HTTP POST) a digitally signed JSON request to the external application.

When all you need is a single page, validating the request and returning the result is all that needs to be done. It becomes trickier when you want to navigate in the application and when that application runs in the cloud with multiple load balanced instances, so you might end up on a different instance mid-flight.

Most of the sample code available uses the sophisticated Canvas JavaScript SDK, so I decided to focus on backend code here.

The project

All the code can be found on Github including sources. Feel free to open issues. To try it out you can deploy it to Heroku (button in the Readme on Github) and configure a Canvas app in Salesforce. Use https://yourappname.herokuapp.com/sfdcauth/hw as Canvas URL

The approach

Build a Spring Boot application that provides an authentication endpoint suitable for a Canvas POST and other endpoints that only allow authenticated access. The security will be provided by Json Web Tokens a.k.a JWT or RFC 7519.

As added challenge: The application will require standard link and form based navigation, so we can't rely on AJAX to provide additional "stuff" into the requests from/to the server. And yes - needs to be able to run on Heroku on multiple instances (Dynos in Heroku language) without the sticky session feature switched on.

Lessons learned

• Spring Boot performs magic. Sometimes a little too much magic
• Base64 isn't Base64. The Java8 decoder works different from the Apache Commons, so the signed checksums don't tally. Pain in the "proverbial" to get the validation code from the SDK running
• Spring security is well thought through. I like the approach: the very moment you add it to a project, all is closed until you specifically open it
• You can't stuff the entire JSON coming from Salesforce back into a cookie
• JSON in Java is still a pain (Bearable with JsonNode)
• The information around custom error pages in Spring is confusing. It seems to have evolved over time and conflicting information is presented
• Json Web Tokens (JWT) rock
• Cookies behave different in Salesforce canvas than in regular iFrames. In an iFrame http cookies are considered "native" to their environment, in canvas they seem to run as third-party cookies (unless I miss something). Stole a few hours tracking the issue down
• Avonni Creator is a nice tool to play with Lightning Design System layouts

As usual YMMV

I am a big fan of NodeRED, so I was delighted to see nodes available to connect to Salesforce.
Since the package was a little behind and support for platform events was still missing, I had a chat with Jeff and we agreed that I would maintain the package moving forward.

I updated the package dependencies to current version and made two main changes to the functionality:

• allow credentials to be read from environment variables. This allows for easy deployment to Heroku
• Support for Salesforce platform events

Deployment to Heroku is a breeze, but requires a few steps that I document here.
The instructions require a basic understanding how Heroku works, so you might want to check out a tutorial first. There are some challenges to overcome:

• I want to be able to test local and on the server
• Storage on Heroku is ephemeral. Any changes written to the server's file system get reset on restart
• Deployment should happen via version control

Prerequisites

• Current version of NodeJS installed (I usually stick to the LTS version)
• GIT client installed (or GIT as part of your favorite IDE)
• Heroku CLI (a.k.a Toolbelt) installed. Install using npm install -g heroku-cli

Project setup (Command line work)

• Create a new directory NodeRedDemo and change into it
• Initialize a new project npm init - fill in suitable defaults
• Create a file .gitignore (content see below)
• add NodeRED and the Salesfore nodes npm install -s node-red node-red-contrib-salesforce
• add a line into package.json (see sample below) in scripts: "start": "node-red --settings ./.node-red/settings.js --userDir ./.node-red"
• create the directories scripts and .node-red
• copy the settings.js file from node_modules/node-red to .node-red - We will edit that file later
• initialize git: git init
• add initial files to git: git add --all and git commit -m "initial creation"
• login to heroku heroku login
• add Heroku: heroku create
• deploy: git push heroku master

Your application should be running on Heroku now. To learn how to use NodeRED, check out a tutorial. Besides running on Heroku you can start the application on local too. Just use npm start and load localhost:1880.

What is missing: protect your NodeRED editor, connect to Salesforce and of course: create your flows.

Keep in mind: every time you redeploy or restart the app, anything stored, including your flow definitions, gets lost.
For permanent results I create my flows in the local instance of NodeRED and commit the flow file (in the .node-red directory) to git, so it becomes part of the deployment.