Introduction
Salesforce is a very popular CRM and if you use it most likely you have developed quite sophisticated workflows on it. Most importantly you may have the need to automate complex logic as well as allow non-technical users to configure this logic by themselves without waiting for a programmer to implement it. If this is the case business rules are definitely the right approach. Having business rules in Salesforce is a critical requirement.
What about using Drools, the popular open source rule engine? Or Red Hat Decision Manager, the supported version of Drools? Any third party business rules engine will need to get input data from Salesforce through some of the available API's. The issue is that there are limits on the number of such calls as well as a cost.
There is a solution to this problem. Salesforce acquired Heroku in 2010. Heroku offers a cloud application development platform. If you are a Salesforce customer and develop applications on Heroku you can take advantage of an add-on called Heroku Connect. This add-on synchronizes Salesforce data with a Postgres database running on the Heroku platform without suffering the limitations or cost mentioned earlier. Clearly Salesforce wants to motivate developers to use Heroku as the platform for serious Salesforce applications.
The solution is now clear: run the KIE Server, Drools business rules and business process run time, on Heroku, and leverage the Heroku Connect Postgres database to read data to process from it as well as to write the output of business rules execution to it.
The question is then how do you get the KIE Server to run on Heroku? Not only that but how can you run Red Hat Decision Manager as a licensed Red Hat customer on Heroku and still get support? Customers can create custom container images with a Red Hat product and still get a reasonable level of support for that product as long as they follow certain rules when customizing the Red Hat official container image for that product. The Red Hat official container image is intended to be deployed on Red Hat Openshift and that is the platform where it receives full support. Heroku is definitely not a supported platform. For Red Hat granting you an exception and give reasonable commercial support in this case is critical that the amount of customization required to get Red Hat Decision Manager KIE Server run on Heroku is absolutely minimal.
Bear in mind that the Heroku platform compared with Red Hat Openshift for example has quite a few critical limitations.
Heroku applications are normally deployed and execute in a container technology called Dyno. This technology is not compatible with OCI container images such as the ones used by Docker or Openshift. An OCI container runs on Heroku on top of a Dyno. The problem is that a Dyno cannot have persistent volume. If a Heroku developer needs persistent volume he has to use a Postgres database available on Heroku. This pretty much rule out deploying Business Central on Heroku because a persistent volume is needed by this application. Business Central will have to run somewhere else where persistent volume is available and deploy the KIE container generated from the business rules project to a KIE Server running on Heroku. In fact one could simply add the business rules executable artifact to the KIE Server image during a custom build and then deploy it with the KIE Container already there. To keep it as simple as possible you will not do that in this exercise.
Another Heroku requirement is that the HTTP port where the KIE Server listens to must be defined as the environmant variable PORT. None of the other ports exposed by JBoss EAP can be exposed because there is only one PORT variable available.
With this limitations in mind you can now proceed with the exercise.
Of course I cannot promise that such a procedure will deploy a Red Hat Decision Manager KIE Server on Heroku that Red Hat will support. The only modification being the HTTP port one can hope that an exception can be made.
Deployment Exercise
Login to the Red Hat Container Registry with docker and pull the latest Red Hat Decision Manager KIE Server container image (version 7.3 at the time of this writing). Run the image and test that it is fine by requesting the server information through the KIE Server REST API. Make sure that you are using the port mapped to 8080 by docker and that you are authenticating to the server with the default credentials.
The Red Hat official container images are intended for deployment on OpenShift. The container CMD is /opt/eap/bin/openshift-launch.sh. If you login to the container and view this script you will see that it starts the JBoss EAP server with a configuration file called standalone-openshift.xml. Copy this JBoss EAP configuration file from the container to the local directory.
The HTTP port is bound in the socket-binding-group section in several places.
You just need to replace it with the environment variable PORT as expected by Heroku.
Now create a .dockerignore file with this content:
as well as a Dockerfile such as this:
Setting the server user credentials in the Dockerfile should not be necessary since it should be possible to pass them as arguments during build but it does not seem to be working. More about this in a moment. Now login to the Heroku CLI and then to the Heroku container registry. Create the Heroku app and then run the container:push command which builds the image and push it to the registry. According to the documentation one should be able to set environment variables in the image during build with --arg VAR1=val1,VAR2=val2 but it did not work for me. Once the image is in the registry the container:release command makes it available and you can test that the KIE server is indeed running on Heroku.
