In a business process point of view, such a time-out could be a boundary timer event. But such an event is mainly used for long running service.
The time-out on service provider invocation aims to be not blocked on non-responsive service-provider. It's a technical time-out.
Such a time-out can be defined in the JBI descriptor of the Activiti service unit, under the section 'consume' of the invoked service provider:
<jbi:jbi ...>
<jbi:services binding-component="false">
<jbi:provides
interface-name="process:vacation"
service-name="process:vacationService"
endpoint-name="autogenerate">
<petals-se-activitibpmn:process_file1>vacationRequest.bpmn20.xml</petals-se-activitibpmn:process_file1>
<petals-se-activitibpmn:version1>1</petals-se-activitibpmn:version1>
</jbi:provides>
<jbi:consumes
interface-name="archiveService:archive"
service-name="archiveService:archiveService">
<petalsCDK:timeout>15000</petalsCDK:timeout>
</jbi:consumes>
</jbi:services>
</jbi:jbi>
In a business process point of view, such a time-out could be a boundary timer event. But such an event is mainly used for long running service.
The time-out on service provider invocation aims to be not blocked on non-responsive service-provider. It's a technical time-out.
Such a time-out can be defined in the JBI descriptor of the Activiti service unit, under the section 'consume' of the invoked service provider: