Prevent a variable from being written to history

Camunda 7 Topics Discussion & Questions
1

I have a process where i call an http service and the response from that service is a json with a base64 field with a file. The body of this answer is very large and for this reason I use the commands:
In my JavaDelegate:

    override fun execute(execution: DelegateExecution) {
      //This response have a big string with more than 100000 characteres
       val response: String = http.get(execution.getVariable("url")) 
       execution.setVariable(RESPONSE_BODY.key, response)

        //... business logic here.

        //in the end process i call 
        execution.removeVariable(RESPONSE_BODY.key)
        execution.removeVariableLocal(REQUEST_BODY.key)       
   }

But I get an error because Camunda engine tries to write the variable RESPONSE_BODY in the history.
How do I remove this variable? Why does removeVariable and removeVariableLocal not work?

2

For lack of knowing better…

If you don’t want to access the response outside of the Delegate code, why set the execution variable at all?

In your business logic, parse/process “response” the way you want to, and set the variable for those portions that you need to keep.

3

Hi @GotnOGuts
I put the body in the execution context because I have a generic delegate like http-connect, in this delegate there is an interceptor that can change the request context (I use it as an httpRequest inside an interceptor in Spring for example). I want to understand how to clean up the execution context and why the methods for this don’t work as expected.

4

Hi @Marcelo_Maico,

the history is configured by the history level: History and Audit Event Log | docs.camunda.org

With a custom history level, you can keep the history free from certain process variables: History and Audit Event Log | docs.camunda.org

Have a look at this example: camunda-bpm-examples/process-engine-plugin/custom-history-level at master · camunda/camunda-bpm-examples · GitHub

Hope this helps, Ingo

2 Likes
5

I guess what I’m trying to ask is:
Why are you trying to create and delete a process-level variable in the same step?

The create is going to create a flag to the engine saying “Add this variable to the history”
The delete is then deleting the variable, so when the engine tries to copy it to history, you get an error.

Sometimes I do things just because that’s the way the examples are set up, and I forget to ask WHY I’m doing something in a particular way. If the process-level variable RESPONSE_BODY.key doesn’t exist before this step, and you don’t want it to exist after this step, why create it at all (with execution.setVariable )?

If you break it apart into two distinct delegates, does it work the way you expect it to then?

1 Like
6

Yes, it doesn’t make sense to create and destroy the variable within the same execution context. What I’m doing now is not messing up the execution with values that I need provisionally. When I need to put things in the execution context, I’ll create a rule to not allow the history to be written to the database.

Thanks.