В предыдущем разделе упоминалось о том, что между субъектами передаются сообщения и какими они могут быть, но до сих пор не было показано, как происходит обмен сообщениями и синхронизация информационного обмена между субъектами.
Существуют два вида информационного обмена: синхронный и асинхронный.
Синхронный и асинхронный обмен сообщениями
При синхронном обмене сообщениями отправитель и получатель ожидают момент, когда сообщения могут быть переданы друг другу, т. е. синхронизируются по времени. Если один субъект хочет отправить сообщение, а субъект-адресат еще не готов его принять, то отправитель ждет его готовности. Однако получатель должен ждать, пока отправитель составит желаемое сообщение.
Недостатком синхронного метода является жесткая временная связь между отправителем и получателем. Это создаст проблемы в реализации бизнес-процессов в виде воркфлоу, особенно за пределами границ компании, и может привести к блокировке сложных процессов в самом «слабом» звене. Во время длительных процессов отправитель и получатель могут ждать друг друга дни и недели.
При асинхронном обмене отправитель может всегда посылать сообщения. Он направляет сообщение в буфер сообщений, из которого получатель его и забирает. Если получатель видит только старое сообщение в буфере, он может забрать только его. Если это оказалось не то сообщение, что было запланировано в процессной модели, то получатель в этом экземпляре процесса блокируется. Чтобы избежать блокировки, получатель имеет возможности забрать все сообщения из буфера и управлять ими. В этом случае он может определить и обработать соответствующее сообщение, как только ему это потребуется.
При этой асинхронной форме обмена сообщениями отправитель и получатель слабо связаны между собой. Проблемой на практике может оказаться физически ограниченный размер приемного буфера, что приводит к тому, что не любое количество сообщений может быть записано. Достижение физической границы буфера из-за его заполнения может привести к непредсказуемому поведению одного из экземпляров бизнес-процесса. Чтобы этого избежать, для методологии S-BPM была разработана концепция Input — Pool (см. подпараграф 5.5.5.2).
Типичным примером обмена сообщениями является «Запрос на КЗ». Подача запроса может произойти задолго до фактического начала путешествия, также до этого момента заказывается гостиница и средство передвижения: эти процессы могут выполняться параллельно или последовательно. Если командировка началась, то это не значит, что процесс завершен, так как теперь нужно подсчитать расходы и запросить их возмещения.
Постоянная синхронизация всех шагов в данном процессе ведет не только к дополнительным затратам, но и является лишней, что хорошо показывает этот пример.
