We’ve often noticed in a variety of forums, that some users have struggled with deploying a delegate class in Runtime after defining it in the properties. Somehow the delegate seemed to be working well until they actually tried to deploy it and then nothing happens. Does this sound like you? We know your pain and have some suggestions to overcome this moving forward.
Why is the delegate class that I defined in the properties not working when I try to deploy it in Runtime?
You can find the full explanation in our documentation, but here’s what you need to know:
- This class needs to implement the org.camunda.bpm.engine.delegate.JavaDelegate interface and provide the required logic in the execute method to be called during process execution.
- When process execution arrives at this particular step, it will execute this logic defined in that method and leave the activity in the default BPMN 2.0 way. The classes that are referenced in the process definition (i.e., by using camunda:class ) are not instantiated during deployment. An instance of that class will be created only when a process execution arrives at the point in the process where the class is used for the first time. If the class cannot be found, a ProcessEngineException will be thrown. This happens when you are deploying, the environment (and more specifically the classpath) is often different from the actual runtime environment.
- This last part is especially important because you won’t see a potential problem (Exception) until the first time the process is run and that class is called. In other words, a successful deployment is not enough proof that there isn’t a problem. You’ll need to have the process running in order to ensure that there won’t be a classpath problem in your Runtime environment.
But wait, what about the properties file?
Ideally, your properties entry should have the following fields (screenshot above):
Id: TestServiceImpl
Name: TestServiceImpl
Implementation: Java Class
Java Class: com.test.lmpl.TestServiceImpl
Asynchronous Before: Unchecked
Asynchronous After: Unchecked
Once your properties entry is set, you’ll want to make sure your TestServiceImpl class looks like this:
public class TestServiceImpl implements JavaDelegate {
public void execute(DelegateExecution execution) throws Exception {
String var = (String) execution.getVariable("input");
var = var.toUpperCase();
execution.setVariable("input", var);
}
}You’re almost there! Now, it boils down to how you are referring to your class in the properties tab ${TestServiceImpl}. But remember that you likely won’t see any problem with your class being referenced until you attempt to run it.
More Help Is On the Way
Give it a try and let us know if you need any additional help. This post is one of many more to come as part of our new Questions that Need Answers blog series we are kicking off. Recently, we were asked what our most popular user questions are regarding Camunda Platform. We decided to look through our forum and Question Corner inquiries to find out, and share the collection of answers with you. We will work down the list and post a scenario along with the solution to help support you with engineering excellence.
Stay tuned for another popular question to be answered in this Questions that Need Answers series.
Camunda Developer Community
Join Camunda’s global community of developers sharing code, advice, and meaningful experiences
