dynamics crm, azure functionapps and java

I had a need to parse documents and create a “text” version of their content for inserting into a dynamics multi-line text attribute. The idea was that the content would be used for search as well as “quick reading.”

Java’s tika library is highly regarded for multi-document parsing, of many types, not just Microsoft Office document but also PDFs etc.

Since the functionality to parse a document and update an entity’s attribute is on a form, we have a few choices to do this:

• Create a web site that we hit with a dynamics crm webhook
• Create a web server that allows us to call REST calls and extract the text.
• Don’t use java and write a plugin to do this.
• Use MS flow to do this.

Dynamics is clearly following the trend of the MS cloud to pull processing out of the server and put it into microservices. Significant innovation is occurring in the azure cloud vs data integration on the dynamics platform. Dynamics will catch up at some point, but for now its better to pull things off platform if its easy.

So what’s easy (and secure) is using a web server to provide REST services callable from a form’s web page through javascript. So let’s do something easy and use azure functionapps. A functionapp is a single function you provide on a pay-as-you-go, per call basis to run a function. That function can pretty much anything. In our case, our function should just parse the document provided to it in the REST call. Since its functionapps on azure, it is easily secured and access from any javascript application we want. We will not cover security in this post, but its easy to adjust the CORS policy and use a javascript dynamics web resource to secure the web service.

Here’s a few links on functionapps that’s relevant:

• https://docs.microsoft.com/en-us/azure/azure-functions/functions-create-first-java-maven
• https://docs.microsoft.com/en-us/azure/azure-functions/functions-reference-java
• https://docs.microsoft.com/en-us/azure/azure-functions/set-runtime-version

To make this more interesting, instead of using java, we’ll use scala and we’ll create a fat jar for the service since its so easy to create.

The key thing to remember is that a functionapp is really a set of functions grouped together in an “application” service that runs like any other web program. In fact it runs much like the old-school CGI programs on web servers from the 1980s. A call comes in, a function within an application (regardless of the language or execution model) is run and the results are returned to the caller. You can think of a functionapp as a function with some programming code that runs on a "virtual’ server that only runs when the function endpoint is called. It’s called serverless computing because you never allocate a server, its handled for you, all you need to do is organize a hierarchy of files that represent the function, the functions “configuration” and the related programming code.

The functionapps are organized on the “server” like:

• wwwroot
  • func1: The function to create, you can have multilpe.
    • function.json: The configuration that describes how to run the function e.g. run a .net/nodejs/java rpgoram.
    • blah.jar: In this case, a java jar file that contains the JVM bytecode. If this was a nodejs program we would have a “index.js” type file that contains our function’s code.