Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision		 Previous revision
en:rule:external_event [2024-08-28 15:47] – created Anatoly Belaychuken:rule:external_event [2024-08-28 16:15] (current) – [0-TBD Use a dedicated process to catch the event initiated by external participant] Anatoly Belaychuk
Line 1: Line 1:
-====== 0-TBD Use a dedicated process to catch the event initiated by external participant ======+====== Use a dedicated process to catch the event initiated by external participant ======
  
 {{tag>process collaboration}} {{tag>process collaboration}}
- 
-{{en:underconstruction.png?nolink&200|}} 
  
 When an event initiated by external participant occurs (e.g. ordered goods are delivered by supplier), it isn't tied to the context (specific purchase order) yet. When an event initiated by external participant occurs (e.g. ordered goods are delivered by supplier), it isn't tied to the context (specific purchase order) yet.
Line 355: Line 353:
 ===== Notes ===== ===== Notes =====
  
-  * Обратите внимание на задачу "Идентифицировать доставку" на диаграмме [[#как надо]]. Эта задача имеет место в реальности: когда на наш склад прибывает фура от поставщика, то первое, что делает наш сотрудник - проверяет сопроводительные документы и выясняет, заказывали ли мы этот груз (возможно, он доставлен по ошибке). Но на диаграмме [[#как не надо]] для этой задачи нет места! +  * Please pay attention to the "Identify purchase" task at the [[#how to]] diagram. This task does exist in reality: when goods from a supplier arrives at our warehouse, the first thing our supervisor does is check the accompanying documents to find out whether we ordered this (it may have been delivered by mistake). But there is no room for this task at the [[#how not to]] diagram! 
-  * Еще одно преимущество схемы [[#как надо]] - она предусматривает возможность, что груз не был принят (например, из-за претензий по качеству и/или количеству) с первой попытке, но был благополучно принят при повторной доставке поставщиком. В этом случае просто будет два экземпляра процесса приемки груза на один экземпляр процесса закупки. +  * Another advantage of the [[#how to]] diagram is that it covers the possibility for goods not to be accepted (for example, due to quality and/or quantity issues) on the first attempt, but be accepted upon re-delivery. In this case, there will simply be two instances of the goods acceptance process for one instance of the purchasing process. 
-  * В приведенных примерах опущен таймер (процесс ждет доставки бесконечно) и другие подробности. +  * The examples presented omit the timer (the process waits for delivery indefinitely) and other details. 
-  * На диаграмме [[#как надо]] изображены два развернутых процесса. При моделировании реальных (а не учебных) процессов лучше изображать каждый процесс [[single_process|на отдельной диаграмме]]. +  * The [[#how to]] diagram depicts two expanded processes. When modeling real (not educational) processes, it is recommended to expand each process [[single_process|on a separate diagram]]. 
-  * Для моделирования взаимодействия между процессами предпочтительнее использовать не событие-сообщение, а [[conditional_event_collaboration|событие-условие]].+  * Better use [[conditional_evingent_collaboration|conditional event]] instead of messages to model collaboration.
  
 ===== Exceptions ===== ===== Exceptions =====
  
-Процесс-обработчик может не потребоваться, если модель процесса является исполняемой, а внешний участник процесса - не человек, а робот (информационная система, веб-портал). +The event process may be redundand if the process model is executable and the external participant is not a human being but a robot (automated system, web portal). 
-Поток сообщений в этом случае моделирует вызов веб-сервиса. +In this case the message flow would model a web service call.
 ===== See also ===== ===== See also =====