BizTalk Internal and External schemas

Question

I'm reading all over the net that you your separate your "external schemas" from your "internal schemas" and never expose the "internal schemas" to any external actor.

If my solution only acts as a messagebus to create a loose coupling between 2 existing systems, will I really need any internal schemas?

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

I can't see the pro's of having an internal schema and map:

SchemaA -> SchemaInternal -> SchemaB

?

Answer 1

The term canonical schema is often used to describe the creation of schemas internal (SchemaInternal in your last example) to an integration mechanism such as BizTalk.

Use of canonical schemas is widely regarded as a best practice, as it decouples your BizTalk flow control mapping from any 'other' system's schemas (other system here could be internal to your organisation or external to it, e.g. a supplier, customer or partner system). This way, if any of the systems integrated via BizTalk change, it is just the external schemas, and maps to the canonical schemas which need to be changed. It also prevents foreign conventions, naming and hierarchy differences inherent in external schemas from leaking into your internal BizTalk artefacts.

Generally, transformation of incoming messages to a canonical schema is done as early as possible e.g. on a receive, and similarly, transformation out of canonical done as late as possible, e.g. on a send port map.

A common scenario for Canonical Schemas (CS) is where a single orchestration or message flow is common to multiple trading parties (e.g. you may have many suppliers with different systems, however, all of them submit invoices for processing). In this case, each new supplier system just needs to be integrated with your CS - no new processing logic needs to be added or duplicated - CS can actually reduce the overall effort in such instances. (The n x m problem is explained in detail here). Another example of where CS are vital is where your business IS switching of messages - e.g. a Medical industry switch will have many doctor and practice systems sending authorisation requests and invoices and these need to be mapped and routed to multiple medical fund (medical aid) systems.

And FWIW:

• IMO CS make most sense in an when BizTalk is the end-end solution in an EAI or ESB scenario, e.g. direct integration of 2 or more line of business systems. Otherwise, if BizTalk is just one endpoint on a larger corporate ESB, then it probably makes sense to use the corporate ESB schemas internally, and hence map external schemas directly to the ESB schemas (i.e. no need for another set of CS within BizTalk, provided that you have a good change management / version control mechanism across your enterprise).
• If standard schemas (e.g. EDIFACT) exist for your industry, it is moot as to whether it is a goal to adopt these as internal CS. In general these may conflict with the meaning of Canonical as being 'simple', as industry schemas often need to be verbose in order to model all flavours and 'edge cases' of the document). Personally I would ensure that I have a mapping to / from said industry schemas, but would use a custom schema internally.

Answer 2

In this context, External = Public, meaning outside your organization.

The guidance is to protect internal implementation details, naming conventions and such, from others.

If both System A and System B are inside your organization then 'security' is less of an issue but your application can still offer an 'external' schema to consumers in order to protect them from internal changes to your application.

Answer 3

In described solution you don't have need in internal schemas. Well you can hide the schemas of System X from users of System Y, but that is not so important.