It’s common to see BPMN diagrams using send tasks to illustrate that we send documents to external entity and receive tasks to model obtaining an answer. Or (which is practically the same) using send message and receive message events for these purposes.
As an example - diagram from Russian Wiki:
Please don’t.
Both send/receive tasks and message events are “robots”, automatic actions. If there is a piece of software on the other side to then it’s OK: bytes go into the network connection to be received and processed on the other side.
But buyer is a human, you can’t “call” him as a web service! He communicates with us by phone, by email, by sending paperwork with courier - anyway it’s a communication with a human: our employee would receive email or documents, read them and decide what to do with the information obtained.
Therefore:
- If the process automatically (i.e. pure programmatically, without human intervention) communicate with an external service then use service task, send/receive task and/or send/receive message event.
- If the process automatically sends email then use a script task.
- Otherwise do it with a user task because in the real life buyers, suppliers, partners, agencies communicate not with a process directly but via human participants.
А как тогда корректно изобразить, что мы ждем отклика на наше КП, который может поступить в любой случайный момент после отправки КП клиенту? У нас же никто не занимается в это время задачей с неопределенной длительностью “Получить от клиента отклик на КП”. Т.е. ситуация не подходит под первые два пункта вашего перечисления “Поэтому”, а в третьем написано, что “только user task”. Или вы имеете в виду, что для полной корректности должен быть отдельный процесс “Разбор входящих”, в котором с какой-то периодичностью выполняется user task по разбору входящей почты от клиента, а вот оттуда в текущий процесс уже автоматически прилетает message event? Для исполнимого BPMN, согласен, это важно, но если процесс моделируется не для исполнения, а для осознания, то можно, я думаю, закрыть глаза на такие допущения.
Кстати, по поводу роботов, общающихся с роботами - встретил тут где-то недавно аббревиатуру, входящую в моду: M2M. Обозначает взаимодействие “Machine-to-Machine”.
Но, кстати, системы межведомственного взаимодействия в рамках программы “Электронное правительство”, насколько я понимаю, примерно так и работают, как бы это ни называли.
Дмитрий
Не судите слишком строго эту схему - я тут акцентировал внимание на одном аспекте, взяв в качестве боксерской груши схему из википедии, и не задавался целью разработать эталонный процесс подготовки КП. Кстати, исходная идея у меня была взять кривую схему из стандарта - но нет, там оказалось все в порядке.
Если же разбираться с предметной областью всерьез, то тут два процесса: один заканчивается тем, что клиент акцептует (или не акцептует) наше предложение по формальным признакам; второй начинается (или не начинается), когда он приходит уже с заказом - может быть держа в руках наше КП, а может быть и просто так. Чтобы привести к этому эталонному виду вторую схему, надо переименовать процесс в “От обращения до КП”, последнюю задачу в “Отправить предложение” и последнюю развилку в “Предложение акцептовано”.
Анатолий
Вы пишете “Если хотите показать, что процесс автоматически (т.е. чисто программно, без участия человека) взаимодействует с внешним сервисом – используйте для этого service task”.
Т.е., если в процессе предусмотрено обращение к АБС и соотв. возврат данных, достаточно использовать сервис таск, не нужно рисовать пул (или что это в схеме вики “Покупатель”) для АБС и использовать message flow для обращения?
Елена
Совершенно верно. Принципиальная разница между Покупателем и АБС та, что у Покупателя есть собственная воля. Поэтому ему нелья поставить задачу в рамках пула процесса. АБС - можно. К тому же оркестровка еще и проще - зачем усложнять без нужды?
Отдельный пул для АБС и обмен сообщениями понадобятся в том случае, если это не просто синхронный вызов функции “запрос-ответ”, а нечто более сложное, асинхронное - см. последнюю пару примеров в http://mainthing.ru/ru/item/613/