Внутренние и внешние схемы BizTalk

Question

Я читаю по всей сети, что вы отделяете свои «внешние схемы» от ваших «внутренних схем» и никогда не подвергаете «внутренние схемы» любому внешнему актеру.

Если мое решение действует только как messagebus для создания свободной связи между двумя существующими системами, мне действительно нужны внутренние схемы?

System A makes a Request(Message with SchemaA) to Biztalk 

Biztalk Maps SchemaA to SchemaB 

Biztalk forwards request of type SchemaB to SystemB 

SystemB returns ResponseB 

Biztalk maps ResponeB to ResponeA 

Biztalk routes the result back to System A 

Я не могу видеть профи наличия внутренней схемы и карты:

SchemaA -> SchemaInternal -> SchemaB

?

Answer 1

Термин canonical schema часто используется для описания создания внутренних схем (SchemaInternal в вашем последнем примере) для механизма интеграции, такого как BizTalk.

Использование канонических схем широко рассматривается как best practice, поскольку оно отделяет отображение управления потоком BizTalk от любых схем «другой» системы (другая система здесь может быть внутренней для вашей организации или внешней к ней, например, поставщик, клиент или партнерской системы). Таким образом, если какая-либо из систем, интегрированных с помощью BizTalk, изменится, это просто внешние схемы и отображает канонические схемы, которые необходимо изменить. Это также предотвращает утечку внешних соглашений, именования и иерархии, присущих внешним схемам, в ваши внутренние артефакты BizTalk.

Как правило, преобразование входящих сообщений в каноническую схему выполняется как можно раньше, например. на прием, и аналогичным образом преобразование из канонического, выполненного как можно позже, например. на карте порта отправки.

Общепринятый сценарий для канонических схем (CS) - это то, что один общий оркестровый или поток сообщений является общим для нескольких торговых партий (например, у вас может быть много поставщиков с разными системами, однако все они отправляют счета для обработки). В этом случае каждая новая система поставщиков просто должна быть интегрирована с вашей CS - никакая новая логика обработки не должна добавляться или дублироваться - CS может фактически уменьшить общие усилия в таких случаях. (Проблема n x m подробно объясняется here). Другим примером того, где CS жизненно важно, является то, где ваш бизнес переводит сообщения - например, переключатель медицинской отрасли будет иметь множество систем для врачей и практики, отправляющих запросы на авторизацию и счета-фактуры, и их необходимо сопоставить и перенаправить в несколько медицинских фондов (медицинскую помощь).

И FWIW:

• IMO CS наибольший смысл в когда BizTalk является конечным комплексное решение в EAI или сценарии ESB, например,прямая интеграция двух или более бизнес-систем. В противном случае, если BizTalk - это всего лишь одна конечная точка на более крупной корпоративной ESB, то, вероятно, имеет смысл использовать корпоративные схемы ESB внутренне и, следовательно, отображать внешние схемы непосредственно в схемы ESB (то есть нет необходимости в еще набор CS в BizTalk, при условии, что у вас есть хороший механизм управления изменениями/версией управления на вашем предприятии).
• Если стандартные схемы (например EDIFACT) существуют для вашей отрасли, это спорный вопрос, как того, является ли это целью принять их в качестве внутренней CS. В общем случае они могут противоречить значению Canonical как «просто», поскольку отраслевые схемы часто должны быть подробными, чтобы моделировать все вкусы и «краевые случаи» документа). Лично я бы удостоверился, что у меня есть сопоставление с/из указанных отраслевых схем, но будет использовать собственную схему внутри.

Answer 2

В описанном решении у вас нет необходимости во внутренних схемах. Ну, вы можете скрыть схемы System X от пользователей System Y, но это не так важно.

Answer 3

В этом контексте External = Public, что означает вне вашей организации.

Руководство предназначено для защиты внутренних деталей реализации, соглашений об именах и т. Д. От других.

Если в вашей организации находятся как система A, так и система B, то «безопасность» - это не проблема, но ваше приложение все еще может предлагать потребителям «внешнюю» схему, чтобы защитить их от внутренних изменений вашего приложения.