T2.1: Adds Production Components

Overview

When building HL7 interfaces in InterSystems HealthConnect, you have several methods for adding production components. The "Create New" functionality allows you to add a completely new component from scratch.

Creation Process

• Start by selecting the component type (Business Service, Business Process, or Business Operation)
• For HL7 components, select the adapter type:
• TCP: Real-time connections
• File: File-based processing
• FTP: Remote file transfers
• HTTP: Web services
• SOAP: SOAP-based integrations

Initial Configuration

During the creation process:

• Configure the most relevant parameters for the selected adapter type
• TCP adapter: Requires port configuration
• File adapter: Needs a directory path (FilePath)
• All settings can be modified later through the component configuration interface

Adapter Selection Guidelines

• TCP adapters: Real-time, persistent connections with remote systems
• File adapters: Batch processing, shared directory communication
• FTP adapters: Remote file transfer capabilities
• HTTP/SOAP adapters: Web service integrations
• Each adapter type has specific configuration requirements and behaviors

When to Use "Create New"

Best when you need a component with unique configuration that doesn't match existing components:

• Start with default settings appropriate for the adapter type
• Build configuration to match specific integration requirements

Overview

The Copy function provides an efficient method for creating new components when you already have a similar component configured in your production.

Use Cases

Particularly useful when you need:

• Multiple instances of the same type of component with similar configurations
• Example: Send HL7 messages to multiple external systems via TCP
• Copy an existing HL7 TCP Business Operation and modify only destination-specific settings

What Gets Copied

When you copy a component, all configuration settings are duplicated:

• Pool size
• Alert settings
• Credentials references
• Adapter-specific parameters
• This ensures consistency and reduces configuration errors

Rename Limitation

InterSystems HealthConnect does not provide a direct "rename" function:

• Must use the Copy function to create a new component with the desired name
• Then delete the original component
• This copy-and-delete workflow preserves all configuration

Important Considerations

Be careful with settings that reference external resources:

• Credentials: May need to be updated
• File paths: Often environment-specific
• IP addresses: Usually need changing
• Ports: May conflict with other components
• The Copy function is a time-saver but requires careful review of all settings

Overview

InterSystems HealthConnect provides comprehensive deployment tools for moving productions between environments (Development, Test, and Production).

Navigation

Access the import process through:

• Interoperability → Manage → Deployment Changes → Deploy
• This centralized deployment interface ensures consistency
• Provides safety mechanisms for production deployments

Automatic Rollback Feature

A critical safety feature:

• Deploy function exports the entire current configuration to an external rollback file
• Creates a complete backup of the existing production state before import
• Allows you to reverse a failed deployment and return to previous working state
• Minimizes downtime and risk during deployments

Deployment Bundle Contents

The bundle contains all production definitions in a single file:

• Production definition itself
• All Business Services, Business Processes, and Business Operations
• HL7 message definitions
• Routing rules
• Lookup tables
• Custom schemas
• Data Transformation Language (DTL) transformations
• May need to manually add custom classes outside standard production components

Best Practices

Before deploying to production:

• Always test the deployment in a TEST environment
• Validate that all components import correctly
• Verify the rollback process works as expected
• Check environment-specific configuration differences
• The deployment process compiles all components, which can reveal errors

Overview

The export process begins from the Production page using the Actions menu and selecting Export. This creates a comprehensive deployment package for deploying complete HL7 integrations across environments.

Export Contents

The export includes:

• Production definition itself
• All configured Business Services, Business Processes, and Business Operations
• HL7 message definitions
• Routing rules
• Lookup tables
• Custom schema definitions
• DTL transformations

Dependency Detection

The deployment tool attempts to automatically detect all dependencies:

• May not capture custom classes that aren't standard production components
• Example: Custom business logic classes or utility classes
• Export interface provides buttons to manually add additional elements
• Ensures all dependencies are captured

Repeat Export

When you need an updated export:

• Use the "repeat export" button
• Creates new versions without reconfiguring export settings each time
• Particularly useful during iterative development and testing cycles

Configuration Values Warning

Critical to understand:

• Configuration settings export with the values currently set in Development
• IP addresses, ports, file paths all export as-is
• When imported to Test or Production, these values are imported too
• Potentially causes connections to wrong servers
• This is why Default Site Settings are essential for environment-specific values

The Challenge

One of the most important challenges in production deployment:

• When you export from Development, all configuration settings export with Development values
• Includes IP addresses, port numbers, file paths, credentials
• Importing to Test or Production would configure those environments to use Development resources

The Solution: Default Site Settings

Default Site Settings solve this challenge:

• Defined outside of the production definition itself, at the site or environment level
• When configured for a particular component and setting, it takes precedence over imported values
• Allows exporting production with Development values intact
• Test and Production environments use their appropriate values

Example: SMTP Server Configuration

• Development, Test, and Production each have different SMTP servers
• Define a Default Site Setting in Test and Production for the SMTP server IP address
• During deployment, Development SMTP IP is imported but immediately overridden
• Each environment connects to its correct SMTP server without manual changes

Wildcard Notation

Default Site Settings can use asterisk (*) for multiple components:

• Apply a file path setting to all Business Services that use File adapters
• Apply a pool size setting to all Business Operations
• Provides powerful flexibility for managing configuration
• Maintains environment-specific control

Common Use Cases

• SMTP servers: Different email servers per environment
• Database connections: Environment-specific databases
• File paths: Different directory structures
• IP addresses: Environment-specific endpoints

Fundamental Best Practice

Always test the deployment in a TEST environment before deploying to PRODUCTION:

• This testing phase prevents production outages
• TEST environment should mirror production as closely as possible
• Same InterSystems IRIS version, configuration, and system settings

Validation During TEST Deployment

Verify that all components import correctly:

• Check for compilation errors
• Ensure all dependencies are included in the deployment package
• Look for warnings or errors during import
• Check for missing classes or resources
• Run test messages through the production
• Validate routing rules, DTL transformations, and component configurations

Test Rollback Functionality

In your TEST environment:

• Deliberately create a scenario where you need to rollback
• Verify the rollback file was created correctly
• Confirm the rollback process successfully restores previous state
• Understanding rollback is essential before using it in production emergency

Validate Default Site Settings

Confirm environment-specific Default Site Settings:

• Ensures mechanism will work when deployed to PRODUCTION
• Check database connections
• Verify file paths
• Confirm IP addresses point to TEST resources, not Development
• Validate any other environment-specific settings

Overview

While InterSystems HealthConnect provides standard HL7 components suitable for most scenarios, custom component classes are sometimes needed for:

• Specific business logic
• Unique integration requirements
• Advanced HL7 interface development

Component Class Structure

Production components are ObjectScript classes that extend base production component classes:

• Business Services: Extend Ens.BusinessService
• Business Processes: Extend Ens.BusinessProcess
• Business Operations: Extend Ens.BusinessOperation

Base classes provide framework for:

• Integration with the production environment
• Message handling
• Error handling
• Configuration management

Custom Business Services

Typically implement specific message reception logic:

• Reading from proprietary file formats
• Receiving messages through custom protocols
• Use adapters for connectivity aspects
• Business logic focuses on message processing, not connection management

Custom Business Processes

Implement complex routing or orchestration logic:

• Beyond what can be achieved with standard routing rules
• More than DTL transformations can handle
• Multi-step workflows
• Complex decision making

Custom Business Operations

Handle specific requirements for sending messages:

• Custom formatting requirements
• Protocol handling
• Acknowledgment processing required by target system
• Use adapters for connectivity, separating connection management from business logic

Best Practices

When creating custom components:

• Follow InterSystems best practices for error handling
• Implement proper logging
• Use configuration management
• Ensure seamless integration with production environment