I’m new to Camunda and started with a docker image (camunda/camunda-bpm-platform:latest) to get more involved in functionality, best practices and the rest API of Camunda.
I also wanted more less Java because i come from python backend developing.
Now I’m at the point to integrate a new script engine: Python, but it’s not running.
The error i get is:
can’t find scripting engine for python - scriptengine is null or
can’t find scripting engine for jython - scriptengine is null
I added in the pom.xml (/camunda/webapps/camunda/META-INF/maven/ pom.xml)
org.python
jython
2.7.2
and put the jython-2.7.2.jar file (jython.org) in /camunda/webapps/camunda/WEB-INF/lib/
But i don’t know how. I couldn’t find any description where to activate in docker such libraries and to use them right.
Maybe someone can help me.
Hi @Jako
Welcome to the forum
Generally adding python/Jython as a scripting engine to Camunda shouldn’t be the first choice.
If you want to use python for your business logic then you should use the external task pattern to run your python code. That way you won’t need to mess around with the engine.
Luckily there’s a really great blog post that was written about how exactly to implement this for python that i think should help
Also many thanks to @Niall for your Tutorial Videos, I saw them all.
I made already a Python worker which is working fine but i do not understand why an extra service should run for only a simple single call of an „fast“ answering rest api call!?
Do I understand you correctly that you want to execute a rest call with your jython script?
The difference to the external task pattern is the “actor”. A script task “pushes” it’s workload to some external API, while an external task “pulls” workload when the external worker is ready.
It is a design choice you have to make for yourself. Wit the external task pattern all my implementation logic is outside of camunda and I can run the camunda bpm platform purely as service. If I had script tasks, I had implementation details inside the platform, which makes maintenance more difficult in my setup.
I‘m playing with camunda to get an overview what‘s possible and what should be done with maybe workers or other crazy stuff i actually not know.
I unterstand that you use camunda as an orchestation tool. That was my First intension too, but it maybe can do much more for me, like a little call here or a calculation there. And is an integrated dmn not a little workload too?
@Noordsestern
Coming to your question, yes i thought using Python for calling a rest service can be a way. I‘m in testing and evaluation stage i also know what you mean with less maintaining and maybe readable and transparent process code. Thanks for that hint.
Please, feel free to convince me that this is a bad idea, i‘m still mind opened! You see i need a little bit support to find my way…
For me it is not clear which way i‘m going in the future.
My first step was to use camunda with bpmn.
Next (now), i try to understand what all camunda can do for me and my company. (Background: Our architecture is build with microservices (yes, i saw the webinar orchestrating microservices from @BerndRuecker too ), RPA, OCR and magical external software. We started with a nice big bunch of a tech stack, but we try to minimize the tech stack and hope that camunda can help us to organize these little tech zoo, instead of creating a new backend Stage in language X and a new tool for that in language Y.)
Sorry. that‘s a little bit off topic, but i‘m very happy to talk with all of you about my start and experiences with camunda and i‘m strongly convinced that this is the next big thing for us to enable our customers to have more time to do really important things.
OK, I thought about it again.
Depending on @Niall first answer not to use a script task, is it better to use a http/soap-connector for a rest or a soap call, or is this also not best practice?
No, those connectors are discouraged. I let the camunda people explain, the reasoning is always slightly different but in essence: connectors are somehow buggy or unstable. Haven’t tried it myself, though.
Thanks to @Noordsestern to preserve me for using buggy code. It would be very interesting for me why not to use the connectors!!!
But OK, is the only and right way to implement a Rest call using external tasks?
Even if i have 4, 5, 6 calls one after an other?
Or is creating an own java class the most used implementation?
But how would that fit (writing Java classes) in my docker container infrastructure (all microservices are dockerized)
I don‘t know!
That means that java Knowledge must be build instead of purely using the camunda-Rest-API…
Am I wrong?
How do you call your existing Rest-APIs over camunda?
Camunda was originally for java developers. The approach is different than with external task pattern. Java developers love to hook complete camunda source code and integrate their logic fully in to the platform With java, a camunda platform instance can be a customized instance with custom java classes.
With external task pattern things are different. Camunda is basically a powerful message queue and your external task workers consume messages provided by the platform. Your python worker fetches workload from camunda as consumers usually consume messages from queues. In this setup, camunda platform is solely used as a service - and since messages/workloads are consumed via camunda rest api, your workers can be implemented in any language, that provides a HTTP library.
We use python, too, with camunda. It is awesome and even though I am a former java developer, I love external task pattern + python much more.
Do you have a service which is listening the whole time to the camunda message queue like a middleware. To route subsequently the work to the APIs which do there stuff?
Camunda Run platform is hosted in docker container (on kubernetes actually) with a PostgreSQL database. You get the “run” version by adding “run” prefix to the container version: camunda-bpm-platform:run-7.14.0
Camunda run is spring boot based, while the other platforms run on either tomcat or wildfly. The detail is only important for configuration: if you use camunda run, you need to consult documentation how to configure spring boot based applications. I find it easier than tomcat or wildfly.
We infact do have python “services” that basically orchestrate api calls like you described. That has several advantages:
Focus. Microservices don’t need to know that their input comes from camunda and thus can be used independently. I can also test “routing service” and microservice independently.
Many services are 3rd party APIs from api platforms, thus you naturally need a middleware to translate between the business view in camunda an the particular api calls to your services.
Usually Apis (and camunda!) have open API specification so instead of building request calls we use python clients that are automatically generated from openapi specs.
But if you try to invoke different systems regarding your development stage (dev - unit test - integration test - acceptance test - production), you need additional process variables to configure your rest calls.
Or if you need to deal with authentications to reach your endpoints, it’s getting complicated.
Once you need more control about the service invocation, the java delegates or external tasks are superior to the connectors.
i also know what you mean with less maintaining and maybe readable and transparent process code. Thanks for that hint.
), RPA, OCR and magical external software. We started with a nice big bunch of a tech stack, but we try to minimize the tech stack and hope that camunda can help us to organize these little tech zoo, instead of creating a new backend Stage in language X and a new tool for that in language Y.)
but in essence: connectors are somehow buggy or unstable. Haven’t tried it myself, though.
