The anticipation has been building for the release of ProcessMaker v3.2 which is now only a couple weeks away. There is a lot of reason for all the anticipation. V3.2 is a big release for ProcessMaker for three main reasons: Quality, Connectivity, and Reporting.
Let’s first talk about the first reason – Quality. V3.2 of ProcessMaker is the first release we are making under the leadership of our new CTO, Taylor Dondich. Taylor is a first-class engineer and a great IT leader. I’ve also learned that he can be a real pain in the *!@!” regarding quality control. V3.2 is the most tested piece of software we have ever released. Over the past year, we have worked very hard to add a new layer of DevOps tools and processes for our QA team. We have added a great deal of formality to our entire release process. For some of our customers, this has translated into what seems like an endless wait for this version 3.2. However, there is no doubt in our mind that we have made dramatic improvements and that it is the correct way to be improving the quality and reliability of our releases.
So now for the cool stuff. In our previous release, you probably noticed that we added a new way to call a REST API. We called it our ProcessMaker Connectors. You can read about them here. Well, that was just the first step. You were always able to call a REST Endpoint from within a ProcessMaker trigger. The connector simply made it much easier to add a new REST Endpoint in a standard library, i.e. our connector library. However, in version 3.2 we take the concept of ProcessMaker as a “Platform as a Service” (iPaaS), one step further. Now we have added the Service Task. The Service Task is a BPMN 2.0 activity type that is something very special when it gets combined with the ProcessMaker Connector Library. The Service Task now allows our process designers to have a visually explicit way to call a connector that connects to a third-party system. Previously, you would have to look at a step in a task and look at the code of a trigger to see what was happening. Now, you can simply use a service task to show visually in a ProcessMaker process map when and how you want to connect to a 3rd party system. We think that this will make mapping processes and integrating to third party systems MUCH easier.
So for example, let’s say you have a process in which we first want to connect to our SAP ERP and then pre-populate a form with SAP data. We need the SAP data for the ECO Request so that our user can select the part or sub-assembly that we want to change. The user should see the parts and the dependent sub-assemblies in a drop-down list on the form.
In this picture, the first task is a Service Task which calls an SAP connector. The SAP connector would be selected from the ProcessMaker public connector library file. The beauty here, as mentioned above, is that this is now visually explicit. I can see in my process what systems are being called, why, and when. For those that love to do this inside triggers and inside steps…”Yes,” you can still do this as well. But for the business analysts out there that are less technically inclined, the service task makes it much easier to understand how and when a process is going to get or put information from or into another system.
As you can see in the picture above, it is now very visual and very simple. I simply go to the Service Task, click on properties, and I am given access to my Connector Library. In the connector library I will find endpoints for popular services like Google Drive, S3, and Box for storage, Google Calendar for Calendaring, Adobe Sign and Docusign and Right Signature for digital signatures, connectors to SalesForce, SAP, and others for enterprise CRM, ERP, etc.
But wait, it gets better. What about all the internal systems that your IT team is building? For those systems, we have the concept of a private connector library. Your internal developers can publish their connectors (APIs) to a private connector library which will make it possible to connect to your internal API driven systems in exactly the same way. This is the way we “enable your ecosystem” of apps so that they can be consumed by ProcessMaker Workflow.
Pretty Cool, right?
Finally, let’s talk about Data Reporting Tools. We have slowly brought out these new tools over the past couple of releases. In v3.2, you will now get visual gadgets as a report option in your report designer. Just as a refresher, let me explain what Data Reporting Tools offers. First, you are able to create a Scope for your reports. This allows you to define who can design a report and what data they can access. You can restrict access at the Table and/or the Field level.
So, now you can create your security model directly in ProcessMaker. Then you can decide what data to show in your report and how to filter that data. And now you can decide if you want to use a Tabular report or a graphical gadget. Of course, everything can be exported to .xls, .pdf, or .doc formats.
There is still more to come on reporting …i.e. you will soon be able to turn any report into a custom dashboard. But I’ll save that for another post. In the meantime, have a look at these sample reports:
