MessageSubscription

Greeting,

I am trying to create a subscription manually via Java API.

All that I managed to find here is:

ExecutionEntity executionEntity = (ExecutionEntity)context;
EventSubscriptionEntity eventSubscriptionEntity = new EventSubscriptionEntity(executionEntity,   EventType.MESSAGE);
eventSubscriptionEntity.setEventName(eventName);
eventSubscriptionEntity.setActivity(executionEntity.getActivity());
eventSubscriptionEntity.insert();

However inser method put a subscription to cache rather than to db:

public void insert(DbEntity dbEntity) {
    // generate Id if not present
    ensureHasId(dbEntity);

    validateId(dbEntity);

    // put into cache
    dbEntityCache.putTransient(dbEntity);
}

Sometimes it cause MismatchingMessageCorrelationException when we try to correlate like here:

camunda.getRuntimeService().createMessageCorrelation(message.getMessageType())
        .processInstanceBusinessKey(message.getTraceId())
        .setVariable(//
            "PAYLOAD_" + message.getMessageType(), // 
            SpinValues.jsonValue(message.getPayload().toString()).create())//
        .correlateWithResult();

because RuntimeService is not able to find the subscription.

My questions are:

  • Is there public API to make a subscription?
  • If mentioned above way is a single one, how can I flush cache in MyJavaDelegate?

Thank you in advance,
Mike

Hi Mike,

The thing is that you are using internal API:

This is not recommended since the internal API can be changed in any time. Other than that you need to have further knowledge in the engine’s implementation so you can handle situation like this (insert method put a subscription to cache rather than to db).

Why do you want to create a subscription explicitly? The event subscriptions are created automatically during the parsing of the process.

Best regards,
Yana

Hi Yana,

Thank you for your quick response.

The idea is is borrowed from Bernd Rücker’s blog and corresponding code. Please follow the link and see FetchGoodsPubSubAdapter.java

I am agree with Bernd that:

Alternative implementation if you prefer having send/receive in one single ServiceTask which is often easier understood by “normal people”

Having such PubSub adapter is definitely more clear in a little more complex requirements like this:
image

In other case we need several events with a gateway.

Thank you,
Mike