BizTalk Best Practices & Coding Guidelines for the IT Services Industry

There are many best practices articles and coding guidelines for BizTalk, that are floating around the net, but they are not very conducive and pragmatic enough to the ‘IT services’ industry (especially in an offshore development model), to leverage them in their turnkey or T&M projects. This article attempts to fill those gaps.

This article is divided into two sections:

- Aims and Goals

- Coding Guidelines

• Naming Convention
• Design Guidelines

 Aims and Goals –

1. If any CR (change request) comes in, it can be accomplished in very less time.
2. If any new person/team is maintaining the code, then debugging and/or enhancements should be very easy.
3. There should not be ANY SIDE EFFECTS.
4. Loose Coupling.
5. Reusability as a result of loose coupling.
6. Should be service oriented and should use network resources/bandwidth as much less as possible.
7. The code (orchestrations, ports, schemas, components) should be readable and should follow prudent and meticulous naming conventions.

Coding Guidelines -

Naming Convention – Here are some naming conventions for the orchestration shapes and other artifacts.

Design Guidelines (Dos & Don’ts) – Here are some design guidelines in the form of Do’s and Don’ts that should be helpful to improve the response and turnaround time for your projects.

1. Break large monolithic orchestrations into multiple orchestrations. This makes the code maintainable and implementing CRs (change requests) would be easier.
2. Communicate between orchestrations using direct binding in the following way:

a) Message Box –> Orchestration Chaining Pattern

b) Forward Partner –> Process Manager Pattern

c) Inverse Partner –> Recipient List Pattern

3. Implement callbacks from child orchestrations using direct port with self correlation –>  Scatter – Gather Pattern.
4. Always expose schemas as WCF Services, not the orchestrations. This bolsters the concept of loose coupling. In this case, an orchestration can be changed, if required, without the need to re-expose it and update the clients thereof.
5. Put a logical group of shapes within Scope shape always. This makes the code readable, because, as and when needed, we could expand or collapse the scopes.
6. Use exception handling always. Use EventLogs to log exceptions. Thus eventvwr becomes a handy tool for developers to find bugs in the program during unit testing.
7. Use System.Diagnostics.Debug.WriteLine for writing debug messages from orchestrations onto the debug output window. This makes life a lot easy for the developers during the course of development.
8. Do not put business logic within functoids, always use BRE for that purpose. This reduces the amount of work, when business logic changes. Just publishing a new policy suffices; one need not rebuild and redeploy the BizTalk artifacts.
9. Use .NET Serializable classes corresponding to schemas for doing complex mappings, avoid using complex inline XSLT. This makes the code unreadable, as there are not many XSLT experts around the corner.
10. Use separate data access layer, with the data exposed as WCF services. Do not use database adapters as they might lead to deadlocks. The reason is that the database adapters shipped with adapter pack create an ambient transaction which is having isolation level of Serializable, whereas the Oracle and SQL Server implicitly uses the isolation level of Read Committed.
11. Try declaring all elements of your schema as xs:string unless otherwise you need integer or double if you need to perform mathematical calculations with the values, for strings are very easy to manipulate and can be converted to any other data type easily if the contents therein are proper. For domain validations, regular expressions could be used, additionally.
12. Always validate/test your schemas, maps, policies before using the same. This way, the developers are assured that the problems now lie with the orchestrations they are working upon.
13. Use BAM for monitoring health & activity of your orchestrations and for incident level reporting. Use pivot tables (excel) for the same. This becomes very handy during post deployment operational maintenance activities.
14. If you need to receive messages from a third-party/organization then keep the target namespace as blank for the corresponding schemas. By doing so, the third-party subscribers could send plain xml messages without the need to bother about the idiosyncrasies of namespace prefixes corresponding to your target namespace of the schemas.
15. Declare datetime as xs:string in schemas and convert them in code or stored procedures as required. The reason is datetime format depends upon the locale settings of the operating system and also the custom coding which precedes before a message arrives at BizTalk from other systems. Now different parts of our planet use different conventions for datetime, for example, in Middle East, an altogether different calendar, viz. Gregorian calendar is used; therefore it is advisable to use strings, as the format of datetime could be anything. The nitty-gritties could be handled in maps and/or orchestrations.
16. Use separate host instances for Receive side, Processing side and Send side. This improves the performance of the BizTalk applications. It also separates the points of failure in the primary site where normally four servers are used, with the first two in NLB (network load balancing), and the other two in Active-Passive cluster mode. The SQL Server, ENTSSO, MSMQ adapters, POP3 adapters, FTP adapters and the in-process host should be on the Active-Passive failover cluster, whereas the isolated host, HTTP, WCF and SOAP adapters could be on the NLB cluster. It is advisable to use hardware NLB as it provides HA (high availability) features too.
17. Try avoiding using orchestrations where messaging only scenario is possible. The maps can be added as Inbound Maps in Receive Port or Outbound Maps in Send Port.
18. Always Provision for Failed Message Routing in your application such that operations personnel can repair & resubmit the message.
19. Schedule DTA Purge & Archive Job to run everyday.
20. Clean up your message box once per year using the stored procedure bts_CleanupMessageBox.sql provided in the BizTalk installation directory.
21. Do not enable message tracking at ports unless you absolutely require it. The size of tracked messages becomes very huge and would soon consume maximum of the disk space, if the load on the servers are high.
22. Take care of zombies when you are going for uniform sequential convoys. Adjust your delays meticulously. Do not continue further processing (with more shapes) once you come out of convoy loop, as this increases the chances of having zombies.
23. For SOA implementations, have separate projects for maps, schemas & orchestrations.
24. Always name your application appropriately and after deployment always add the binding file to the project/solutions. This would ensure that one need not recreate the physical ports if the application is deleted from the BizTalk admin console for some good reasons, just importing the binding file would suffice.
25. For the heavy load scenarios, increase the value of MaxWorkerThreads (throttling feature) in adm_ServiceClass table of BizTalkMgmtDb.
26. Use multiple receive locations within a single receive port, corresponding to multiple ways clients can submit messages to BizTalk from heterogeneous sources. This makes your application more amenable to SOA.
27. Use default values for the nodes in schemas wherever applicable.
28. Use timeout feature of long running transaction scopes for setting delays, rather than using the delay shape. The delay shape is reported to create lot of problems in sequential convoys and parallel convoys.
29. Use ENTSSO as a configuration store for BizTalk applications. Use SSO Configuration MMC snap-in for putting applications and properties thereof containing Key/Value pairs as configuration data. Never ever use BTSNTSVC.EXE.CONFIG for such purposes.
30. Avoid using singleton orchestrations, as this swells up the BizTalkMsgBoxDb very quickly.

Conclusion:

This article gives a handy reference for some Dos and DONTs in BizTalk Server Application Development and Maintenance. Minor deviations in the naming conventions are innocuous, but when these deviations increase, the readability of the code suffers. Also, following the best practices, one’s response time or turnaround time for any piece of work would significantly improve and we all know that the IT developers normally get a bit less than sufficient time to finish their work!

This article has been editorially reviewed by Suprotim Agarwal.

C# and .NET have been around for a very long time, but their constant growth means there’s always more to learn.

We at DotNetCurry are very excited to announce The Absolutely Awesome Book on C# and .NET. This is a 500 pages concise technical eBook available in PDF, ePub (iPad), and Mobi (Kindle).

Organized around concepts, this Book aims to provide a concise, yet solid foundation in C# and .NET, covering C# 6.0, C# 7.0 and .NET Core, with chapters on the latest .NET Core 3.0, .NET Standard and C# 8.0 (final release) too. Use these concepts to deepen your existing knowledge of C# and .NET, to have a solid grasp of the latest in C# and .NET OR to crack your next .NET Interview.

Click here to Explore the Table of Contents or Download Sample Chapters!

Author

Ambar is a Software Architect with twelve years of experience in Microsoft technologies, Open source systems and Unix systems programming, embedded systems. He has worked in various roles mainly as an architect, designer, team leader and developer and has hands on experience with ASP.NET MVC 2 web applications and WPF desktop based applications, as well as smart client applications using latest technologies harnessing .NET Framework 4.0, C# 2010, ASP.NET 4.0, WCF, WF, WPF, LINQ, WCF Data Services and ADO.NET Entity Framework.

He also has extensive experience in Application integration, business process management and service oriented applications using BizTalk Server 2010, ESB Toolkit 2.0, WCF services, SQL Server 2008 Integration Services, OOAD and agile methodology.