Custom http-connector?

Hi Camunda Community,
I’ve been using Camunda for a couple weeks now and I’m loving it! We have a very strong micro-services architecture and that’s been great for accelerating development. Where we’ve been having a tough time is managing processes that overlay the entire suite of micro-services. And Camunda seems to be the silver bullet to solving that issue.

My only problem is that we are a C# and Python house. There’s NO java experience here. And this is leading to a difficult issue. There’s some setup, custom header generation and error handling that needs to be done while interfacing with our REST APIs. All of this CAN be handled by a process and we have instituted sub-processes to handle all of this. But I’ve very much like to create a custom HTTP connector that handles, for instance, getting a new auth-token if an auth error occurs, ect. But, we have really no java experience in house. Could anyone tell me if

a) this is something that’s reasonable to do
b) point me in the right direction of getting started?

Take a look at Replacing Http-Connector with Jsoup usage

You can write it all as a reusable script

Hi @StephenOTT, yea I saw that post and it looks awesome, but I got stuck at “First we added Jsoup to Camunda”. And we don’t use Docker in our technology stack, so I couldn’t cheat and just do that instead.

How do you run Camunda in your stack?

The camunda app server is on AWS EC2 and the DB is on RDS. That way, we can have or other AWS assets communicate with it over VPC and it doesn’t need any public internet access. We use Ansible for config if that helps. Not sure what you are getting at, sorry.

Is it literally as easy as copying that one jar file into lib?

All you have to do is copy the Jsoup jar into the Camunda’s lib folder and restart Camunda. Docker is not relevant. So you can achieve the same results in your ec2

Thanks! Apparently I was making it harder on myself than it needed to be. I thought for sure I’d have to register the extension in Camunda somewhere. BTW, while I have you, is there a similar extension to enable Python scripting?

You will be stuck with Jpython. I believe you just need to drop the jar(s) in the lib folder. I have done it in the past but found jthyons was pretty out of date with mordern python. (IMO at the time). Have you considered using external task pattern for this instead ?

Thanks a bunch Stephen! I looked into Jthon and it looks like it supports Python 2.7. We do mostly Python3, but 2.7’s not that hard to work with. And Jinja2 (a templating engine we use extensively) is pure Python, so we should be able to include it. I’m going to spend some time next week looking into it. Thanks for the lead on Jython and how to install it. I’d seen some references to external tasks, but I’d like to keep all the logic inside the engine if possible.

The external tasks are good because you can just write yourself a pure python app that interacts with the engine Saves you lots of time

@nodfacts What is the point of “keeping all the logic inside the engine”? If the intent is “to have all the source code packaged within bpmn.xml” then nothing stops you to have that with external tasks pattern.

The trick is that external task handlers (implemented in Python or C# whatever) can download the code from Camunda and execute it in their VM. If there is some problem, report it back to Camunda engine, that is covered by API.

I would strongly suggest considering external tasks pattern, as that simplifies maintenance/upgrade of Camunda and keeps engine scalable.

1 Like

@tair Thank you for that clarification. Yes, the main reason for wanting to avoid external tasks was to keep all the code in the .xml. Good to know that we can do that. We thought it’d have to reference external files.

To get going we just started using JS and @StephenOTT Jsoup recommendation. We don’t have any JS gurus, but it seems like everyone’s played with it here and there. So, I think we’ve made the decision that for the relatively simplistic logic we need to reside in process itself, we can just use JS.

@nodfacts another problem of in-engine scripting in my experience was troubles with debugging those scripts. I remember using Groovy for that especially because it was easy to refactor the scripts so that I could run them in my IDE of choice and only then wrap it in a generic function runnable by engine. This was until External Tasks feature shipped in Camunda. Of course, not everything (?) can be done using External Tasks, for example, as of now I’m not sure you can elegantly do out-of-engine scripted decision/fork (for now we have to sort it out with PRE-decision External Task setting some vars).

Here is a example how running your unit tests with scripting within the Ide. Including with nashorn /js supoort https://github.com/DigitalState/Camunda-Spock-Testing/tree/master/End-to-End/src/test/groovy/end-to-end. You can test the scripts independently of Camunda (see the nashorn specific file) and you can test within the process instance it self.

1 Like