# Persisting process variables in case of an exception

**URL:** <https://forum.flowable.org/t/persisting-process-variables-in-case-of-an-exception/5836>\
**Category:** Flowable Engine\
**Created:** [April 14, 2020, 8:50pm UTC](https://forum.flowable.org/t/persisting-process-variables-in-case-of-an-exception/5836 "2020-04-14T20:50:35Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![bijeshcnair](https://yyz1.discourse-cdn.com/flex035/user_avatar/forum.flowable.org/bijeshcnair/32/1452_2.png) [@bijeshcnair](https://forum.flowable.org/u/bijeshcnair)\
**Post date:** [April 14, 2020, 8:50pm UTC](https://forum.flowable.org/t/persisting-process-variables-in-case-of-an-exception/5836/1 "2020-04-14T20:50:35Z")

</div>

HI,  
I have embedded a flowable engine in a spring boot application.  
I have a simple service task which calls a third party API which may fail at times.

In case of HttpServerErrorException, I want the service task to be retried in the specified FailedJobReryCycle(3 times). This is happening as expected as I’'m throwing a RuntimeException.

But after the number of retries, the process variables are not getting persisted.

How do I show the users what went wrong?

I’m not using any database in the application, except the one flowable uses.  
Is there any way to persist

Following is the code in Delegate execute

```
 if(e instanceof HttpServerErrorException){
     
            throw new RuntimeException(e.getMessage());
        }
        else {
        
            throw new BpmnError("ServiceTaskError", e.getMessage());
        }

```

I have an exception boundary event with reference ServiceTaskError.

---

<div class="post-metadata">

**Author:** ![joram](https://yyz1.discourse-cdn.com/flex035/user_avatar/forum.flowable.org/joram/32/26_2.png) [@joram](https://forum.flowable.org/u/joram)\
**Post date:** [April 20, 2020, 10:29am UTC](https://forum.flowable.org/t/persisting-process-variables-in-case-of-an-exception/5836/2 "2020-04-20T10:29:34Z")

</div>

> [@bijeshcnair](#):
>
> But after the number of retries, the process variables are not getting persisted.

When there is an exception thrown, the whole transaction is rolled back. This includes any variables being set before throwing the exception.

If you want to display this to your users, you will need to catch the exception and model in the BPMN model what happens when this exception happens.

> [@bijeshcnair](#):
>
> I’m not using any database in the application, except the one flowable uses.

Can you elaborate what you mean? If you’re using Flowable+Spring Boot there’s always a datasource.

---

<div class="post-metadata">

**Author:** ![bijeshcnair](https://yyz1.discourse-cdn.com/flex035/user_avatar/forum.flowable.org/bijeshcnair/32/1452_2.png) [@bijeshcnair](https://forum.flowable.org/u/bijeshcnair)\
**Post date:** [April 21, 2020, 4:39am UTC](https://forum.flowable.org/t/persisting-process-variables-in-case-of-an-exception/5836/3 "2020-04-21T04:39:13Z")

</div>

HI Joram,  
Thanks for the reply .

> If you want to display this to your users, you will need to catch the exception and model in the BPMN model what happens when this exception happens.

Yes, this is what I’m doing now. In the service tasks, I’m catching Exception and throwing BPMNError and handling it with a boundary event.

But I would like to retry the service tasks a few times before throwing the BPM error. (Service tasks is asynchronous)  
I was indeed able to achieve the retry setting the failed retry cycle and throwing a runtime exception instead of BPMNError. But this will roll back as you said.

How can I know in the service task that it has reached the maximum retries?  
if I can get this number and the retry count set for that services task, then I can throw BPMNerror instead of RuntimeException. Or is there a better way to handle this scenario?

> [@joram](#):
>
> Can you elaborate what you mean? If you’re using Flowable+Spring Boot there’s always a datasource.

Yes. There is a database used by flowable. And only flowable reads/writes data to it.  
We use a microservice architecture and the application data is handled by a different service.  
The context of this discussion is again regarding the number of retries for a service task. I saw this discussion [Retry configuration is not maintained - #3 by sukalpo](https://forum.flowable.org/t/retry-configuration-is-not-maintained/3660/3) in the forum regarding the failed service task retry.  
An approach is mentioned by @sukalpo to store the retries in the database. I cannot go with that approach as I don’t have a database to write. :

---

<div class="post-metadata">

**Author:** ![joram](https://yyz1.discourse-cdn.com/flex035/user_avatar/forum.flowable.org/joram/32/26_2.png) [@joram](https://forum.flowable.org/u/joram)\
**Post date:** [April 29, 2020, 6:53pm UTC](https://forum.flowable.org/t/persisting-process-variables-in-case-of-an-exception/5836/4 "2020-04-29T18:53:55Z")

</div>

> [@bijeshcnair](#):
>
> How can I know in the service task that it has reached the maximum retries?  
> if I can get this number and the retry count set for that services task, then I can throw BPMNerror instead of RuntimeException. Or is there a better way to handle this scenario?

You can get the job entity related to the current execution (the one you’re getting in as a parameter in the delegate) and check the retries (if it’s 1, it’s the last try). And then throw the BPMN error. Wouldn’t that work?

You can get the JobEntity by going through the regular service calls and then #createJobQuery() and #executionId