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’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:

1. 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.
2. 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.
3. 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. 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.

David Simmons is an Internet of Things (IoT) pioneer who has been working in the field for over 15 years. He has also been a DevRel professional for even longer. David is now the Principal Developer Advocate at Camunda. Previously, he was Head of Developer Relations at QuestDB and the Senior Developer Advocate at Influx Data. He has spoken internationally including keynote addresses.

The Featured Blog Posts series will highlight posts from partners and members of the All Things Open community leading up to the conference in October.