docs.intersystems.com
Home  /  Application Development: Creating Productions  /  Best Practices for Creating Productions  /  Design Model for a Routing Production


Best Practices for Creating Productions
Design Model for a Routing Production
[Back]  [Next] 
InterSystems: The power behind what matters   
Search:  


This chapter describes a design model that InterSystems customers have used successfully to build interface routing solutions. As such, it can be thought of as a collection of best practices for developing a routing production.
This chapter describes only one approach. Other implementation strategies can be successful as well. Each organization has its own standards for writing code and conducting programming projects. This chapter simply describes those aspects of a routing production that are unique to InterSystems IRIS™ and that benefit from a carefully structured approach.
In general, the key to a good design is clarity and simplicity. Simplicity does not mean a small number of parts. Simplicity means that each part within the model has a clear function and is intuitively easy to find.
Configuration Items
An production consists of configuration items. There are three types of configuration item:
The following figure expands the diagram of a routing process to show how it uses routing rules to direct the flow of information through the interface. The following figure includes details about the routing rules and data transformations that are only implied by the dotted circle in the diagram above.
A routing process has a routing rule set associated with it. Depending on how the rule set is defined, and depending on the type of message that arrives from the source application, the rule set identifies which of its rules should execute. More than one rule can execute, in sequence, but for simplicity the following figure shows the case where the rule set chooses only one rule. From this point, as shown, a rule can either delete the message or it can send the message to a destination within InterSystems IRIS. If this destination is a business operation, the message then leaves the production on its way to the target application.
Application Specification
Ideally, an application provides an application specification document, or implementation guide, that explains which types of messages the application can send (or receive), and which message segments and pieces of each segment the application sends (or expects) for these events.
A formal document of this kind is extremely detailed, and extremely useful. If a specification document is available, the administrator for the application can show it to you, and can explain to you which of the many possible messages are actually in use in the enterprise.
Even if there is no application specification document, there is usually some informal documentation. Ask the application administrator to see any notes that are available.
As an alternative to documentation, or to validate that the existing documentation is correct, you can examine the messages themselves to determine which types the application sends or expects to receive. Ask the application administrator to provide you with a sampling of the message data, saved in files.
Background information that supports these tasks can be found in subsequent chapters of this book, and in other books:
Production Spreadsheet
It is helpful to maintain a spreadsheet that organizes your information system, application by application. You can create the spreadsheet on paper, or using any software tool that you prefer.
As a general guideline, you should provide a row for each application that provides an incoming or outgoing data feed. In each row, the following columns are useful:
When you begin the project, your initial spreadsheet does not need to describe every application in the information system. You can add to the spreadsheet as you deploy each new interface.
Interface Design
This topic outlines an effective way to keep interface designs modular so that your production remains easy to understand, scale, and maintain at each stage of its development:
The guiding principle is to keep your design modular. That is, develop one interface at a time and use one routing process for each interface. This contrasts with a model in which a single large routing process serves as the routing engine for all interfaces. There are a number of reasons why many routing processes are better than one:
Each configuration item in the production has a specific role to play. Keep each item to its role:
Naming Conventions
This topic explains the importance of naming conventions and provides examples.
Typically you will develop your production incrementally, one interface at a time. There is a temptation to name items “as you go,” and to allow naming conventions to grow incrementally along with the project. InterSystems recommends you do not take this incremental approach to naming conventions.
Remember that a full HIS system can involve hundreds of interfaces. Anticipate the task of managing the routing production once all of these interfaces are included. The name of each component should clearly identify its purpose. This way, developers and system administrators can easily predict a component’s name based on its function.
InterSystems recommends that you establish a full set of naming conventions at the start of the project, and then stick with them. This alleviates the need to backtrack into your production configuration just to correct names.
Any convention that clearly identifies components by function is fine. The following is a full set of naming conventions that several InterSystems customers have used successfully:
For each element of the production, assemble a name from the segments that you have defined:
For more complex designs:
The following topics provide explanations and examples for these naming conventions.
Business Services
Convention
Examples
FromERChart, FromFineOR, FromDeskAdm
Variation
If you have decided to organize an interface so that one application sends messages into InterSystems IRIS via more than one business service, also include a keyword that classifies the MessageTypes that pass through each business service. A typical MessageTypes keyword uses the first three letters of the message structure. In this case the convention for the business service name is FromSourceAppNameMessageTypes.
Routing Processes
Convention
Examples
ERChartRouter, FineORRouter, DeskAdmRouter
If you have decided to organize an interface so that one application sends messages into InterSystems IRIS via more than one business service, also include a keyword that classifies the MessageTypes that pass through each business service to its routing process. In this case the format for the routing process name is as follows:
Variation
Examples
ERChartADTRouter, ERChartORMRouter, ERChartOtherRouter
Routing Rule Sets
Convention
Each routing process has an associated rule set whose rules determine message destinations. The rules direct the messages to data transformations or business operations based on message type, message contents, time of day, or other factors. Name each rule set to match its routing process. That is, for each SourceAppNameRouter, call the rule set SourceAppNameRules. For each SourceAppNameMessageTypesRouter, call the rule set SourceAppNameMessageTypesRules.
Examples
DeskAdmRules
DeskAdmORMRules
Business Operations
Convention
Examples
ToImagit, ToFineOR, ToPindex
Variation
If you have decided to organize an interface so that one application receives messages from InterSystems IRIS via more than one business operation, also include a keyword that classifies the MessageTypes that passes through each business operation.
Data Transformations
Remember that the SourceMessageType and TargetMessageType may have the same name, but represent the same message structure in different schema categories.
Custom Schema Categories
Convention
ApplicationName BaseSchemaNumber
The ApplicationName can represent a sending application or a receiving application.