Эх. Если нужен цикл, значит нужно придумывать, когда его начинать, а когда заканчивать.

"Accept-флажок" внутри деятельности может не иметь входящих потоков. Т. е. initial node для "процесса клиента" заводить не обязательно. Если нужно учитывать время приёма заявки, можно завести [decision node и] сторожевое условие.

"Accept-флажок" внутри деятельности может не иметь входящих потоков. Т. е. initial node для "процесса клиента" заводить не обязательно. Если нужно учитывать время приёма заявки, можно завести [decision node и] сторожевое условие.

Прошу прощения, не уловил

Если несложно, не могли бы вы изобразить графически:

1) Процесс клиента : инициируется каждым приходом клиента. Заявка помещается в очередь для перемещения со статусом необработано
2) Процесс перемещения: все заявки из очереди для перемещения переносятся в очередь для обработки
3) Процесс обработки: из очереди берется  необработанная заявка в порядке ее поступления и обрабатывается. После обработки меняется ее статус

Во вложении я изобразил свое видение, но боюсь оно некорректное.

Насколько Loop эквивалентен pool в bpmn?

Замечание о необязательности initial node оказалось невполне уместно. Без него не получится сделать цикл. Примерный вид диаграммы во вложении.
Loop на диаграммах деятельности, как мне кажется, нужен лишь в тех случаях, когда планируется генерировать структурированный код по диаграмме. Сделать кодогенератор, который породит код "без goto" по диаграмме из вложения не так просто, как генератор по loop. BPMN не знаю, поэтому не комментирую.

Коллеги, спасибо всем за ответы! Есть над чем подумать.

Пока всё-таки выходит, что BPMN предпочтительней.

Замечание о необязательности initial node оказалось невполне уместно. Без него не получится сделать цикл. Примерный вид диаграммы во вложении.

Спасибо большое!

Вопрос по диаграмме из примера по третьему процессу :

Как реализуется цикличность обработки каждой заявки?

Пока всё-таки выходит, что BPMN предпочтительней.

Для описаний бизнес-процессов безусловно. Для описания и даже для исполнения сложных межпроцессных взаимодействий (bpms, bpel) тоже. Но bpmn - это чисто процессная нотация - в ней нет средств описания данных, их можно приводить только как артефакты.

У UML преимущество в универсальности и разнообразии форматов. В рамках UML можно описать концептуальную модель предметной области в виде диаграммы классов, а потом эти же сущности использовать в поведенческих диаграммах.

То есть если нужно разобраться с БП, то лучше BPMN придумать что-либо сложно, но если нужно спроектировать приложение, то нужен UML.

Вот и хотелось всё нарисовать в UML, дабы не плодить сущности без необходимости.
Преимущества поддержки одной диаграммы вместо двух (да ещё в разных нотациях) очевидны.

Как реализуется цикличность обработки каждой заявки?

Сначала скажу, что моя версия диаграммы лишь демонстрировала, как я представляю себе цикличность "процесса клиента". Она полна недостатков. Например, можно составить вариант с одним, а не двумя datastore. Есть и другие пробелы.
Теперь по Вашему вопросу:
Никак. Перемещение заявок съедает все предлагаемые ему объектные токены и токен управления и разом их переваривает, выдавая на выход кучу токенов перемещённых заявок. Если важно/нужно, чтобы заявки перемещались по одной, то нужен явный цикл (похожий на клиентский). То же самое справедливо для "обработать заявки".

Еще раз спасибо за предложенное решение

Если важно/нужно, чтобы заявки перемещались по одной, то нужен явный цикл (похожий на клиентский). То же самое справедливо для "обработать заявки".

А если перемещаются заявки чохом, а затем докладываются в общую папку для индивидуальной обработки?

Если мы сделаем в третьем процессе цикл goto с join аналогичный первому, будет ли это означать, что индивидуальные токены заявок восстановлен из общей кучи, куда их сунули при перемещении?

.

Если мы сделаем в третьем процессе цикл goto с join аналогичный первому, будет ли это означать, что индивидуальные токены заявок восстановлен из общей кучи, куда их сунули при перемещении?

Это возможно, но при этом на поток данных из второго datastore надо вешать select, определяющий в каком порядке выбираются заявки из общей кучи. Вместо цикла можно было бы задействовать <<iterative>> expansion region, если бы я знал как набор токенов-заявок превратить в один токен-коллекцию-заявок.