Book.od.ua Книги для вашего бизнеса



Одесская библиотека бизнес литературы
полезные книги для бизнеса

1.15. Изменение адреса клиента

Каждому клиенту ПРУСТ соответствует несколько различных адресов, например адрес доставки и адрес, на который высылается счет. Чтобы избежать дополнительных издержек, необходимо позволить клиенту самостоятельно изменять эти адреса с помощью Web-интерфейса.
Для передачи обновленной информации в биллинговую систему, а также в систему доставки товара можно применить один из двух способов:
• включать данные об адресах клиента в каждое сообщение о размещении нового заказа;
• реплицировать обновленную информацию в каждую из систем.
Преимущество первого подхода заключается в том, что для его реализации можно использовать существующие каналы интеграционного решения. В то же время это означает необходимость передачи дополнительной информации с каждым сообщением, хотя изменение адреса клиента происходит не так уж и часто.
При реализации первого подхода следует помнить, что биллинговая система и система доставки товара представлены коммерческими приложениями, не обладающими встроенными средствами интеграции. Следовательно, существует большая вероятность, что эти приложения будут использовать адреса, хранящиеся в собственной базе данных, а не адреса, полученные вместе с сообщением. Чтобы каждая из упомянутых систем обновляла адреса клиента на основе информации, содержащейся в сообщении о размещении нового заказа, воспользуемся диспетчером процессов (Process Manager, с. 325). Диспетчер процессов принимает сообщение о размещении нового заказа (содержащее адреса клиента), а затем передает биллинговой системе (системе доставки товара) два сообщения, как показано на рис. 1.23.
Изменение адреса клиента
Следует помнить, что адаптеры канала (Channel Adapter, с. 154) принимают на вход частные сообщения, т.е. сообщения, отформатированные в соответствии с требованиями конкретного приложения. Поскольку сообщение о размещении нового заказа имеет канонический формат, его необходимо преобразовать с помощью транслятора сообщений (Message Translator, с. 115). Несмотря на то что логика преобразования может быть встроена в диспетчер процессов, использование внешних трансляторов сообщений является более предпочтительным (дополнительная функциональность может привести к возрастанию сложности реализации диспетчера процессов).
Второй подход к распространению обновленной информации об адресах клиента заключается в ее репликации. Как только клиент изменит один из своих адресов, эта информация будет передана всем использующим ее системам с помощью канала "публикация-подписка" (Publish-Subscribe Channel, с. 134). Каждая система хранит адрес клиента с помощью внутренних механизмов и использует его при поступлении сообщения о размещении нового заказа. Данный подход позволяет уменьшить объем трафика сообщений (при условии, что клиенты будут размещать заказы чаще, чем изменять адреса), а также снизить степень связывания систем. Всякая система, использующая адресную информацию клиента, может подключиться к соответствующему каналу "публикация-подписка", не затрагивая при этом другие системы.
Поскольку клиент имеет несколько различных адресов (адрес доставки и адрес, на который высылается счет), следует позаботиться о том, чтобы системам передавались адреса нужных типов. Другими словами, биллинговая система не должна получить сообщение об изменении адреса доставки товара. Эту функциональность можно обеспечить с помощью фильтров сообщений (Message Filter, с. 253), пропускающих только те сообщения, которые удовлетворяют определенному критерию (рис. 1.24).


Понравился материал? Поделитесь с друзьями!

<< Предыдущая статьяСледующая статья >>
1.14. Проверка состояния заказа. Продолжение. 1.16. Изменение адреса клиента. Продолжение.





Убедительная просьба при использовании любых материалов Одесской электронной бизнес-библиотеки ставить активную ссылку на наш сайт. По всем вопросам касательно сайта пожалуйста пишите на почту
      Карта сайта