Summary
Add a Production Assistant to PyProd that inspects an existing IRIS interoperability production and generates an editable PyProd definition using the PyProd APIs.
The generated Python code would preserve the production’s components, configuration settings, adapter settings, class references, and connections wherever they can be represented by PyProd.
The assistant would migrate the production configuration into PyProd code while existing business logic remains in place.
Goal is to give teams with established IRIS productions a practical way to adopt PyProd without manually rebuilding an entire production.
Problem
PyProd provides a code-first approach for defining an interoperability production in Python and loading it into IRIS. However, many organizations already have large interoperability productions that were created and maintained through the Production Configuration page. These productions may contain lots of Business Services, Business Processes, Business Operations, adapters, schedules, and configuration settings.
To manage one of these existing productions with PyProd, a developer would need to manually recreate its configuration in Python which is time-consuming and error-prone. This creates a significant adoption barrier.
Proposed Functionality
1. Generate a PyProd definition from an existing production
Provide a command or API that connects to an IRIS namespace, reads an existing production in read-only mode, and generates a Python production definition.
Something like this:
pyprod generate \
--from-production Hospital.ADTProduction \
--target-class Hospital.PyProd.ADTProduction \
--output src/adt/production.py \
--report migration-report.json
The exact command and option names are only examples. Generation should also be deterministic.
2. Preserve existing implementation classes
The assistant should convert the production definition and configuration without the need for underlying application logic to be rewritten.
3. Create a detailed migration report
The tool should generate a migration report alongside the Python file.
Example:
Source production: Hospital.ADTProduction
Target production: Hospital.PyProd.ADTProduction
Configuration items discovered: 52
Configuration items generated: 52
Settings discovered: 238
Settings represented in PyProd: 231
Credential references externalized: 2
System Default Settings detected: 3
Unsupported settings: 2
Custom production methods requiring review: 1
Result: REVIEW REQUIRED
4. Support side-by-side verification
After generating the PyProd definition, developers should be able to load it under a different production class or into a separate test namespace.
A verification command could compare the original production with the generated candidate:
pyprod verify \
--source Hospital.ADTProduction \
--candidate Hospital.PyProd.ADTProduction
The comparison should be based on semantic configuration rather than only comparing source text.
Example output:
[PASS] 52 of 52 configuration items matched
[PASS] All referenced component classes matched
[PASS] All supported host and adapter settings matched
[WARN] Three settings depend on System Default Settings
[FAIL] One custom setting has no current PyProd equivalent
Benefits
Specific Use Case
A hospital has an existing HL7 interoperability production that has been developed and maintained for several years. The team wants to manage the production through Git and PyProd.
However, manually recreating the full production in PyProd would require developers to copy hundreds of settings and then verify nothing was missed.
A developer runs:
pyprod generate \
--from-production Hospital.ADTProduction \
--target-class Hospital.PyProd.ADTProduction \
--output src/adt/production.py \
--report migration-report.json
The assistant reads the production without modifying it and generates a PyProd definition. Generated Python continues to reference the hospital’s existing Business Services, BPL processes, DTL transformations, routers, and Business Operations by class name, while related BPL processes, DTL transformations, and other dependencies remain in place.
The migration report shows:
Configuration items discovered: 50
Configuration items generated: 50
Settings discovered: 230
Settings represented successfully: 224
Credential references externalized: 2
System Default Settings detected: 2
Unsupported settings: 1
Custom production methods requiring review: 1
The report explains that one custom adapter setting does not yet have a direct PyProd representation. It also identifies two values supplied through System Default Settings and warns that a custom method exists on the original production class.
The development team reviews the generated Python and migration report in a pull request.
After resolving the unsupported setting, the team loads the generated definition under a new production class in a test namespace. The original production remains unchanged.
The team then compares the two productions:
pyprod verify \
--source Hospital.ADTProduction \
--candidate Hospital.PyProd.ADTProduction
The verification confirms that all supported production items, class references, settings, schedules, and component connections match.
After the migration, the production definition is maintained in Python and Git.
Expected Result
The feature would give existing IRIS customers a practical way to begin using PyProd without manually reconstructing an entire production.
Existing IRIS production
↓
Generated PyProd definition
↓
Developer review and validation
↓
Testing in a separate environment
↓
Controlled migration
Developers would be able to generate a reliable starting point, understand what was and was not converted, protect sensitive information, compare the result with the original production, and adopt PyProd without rebuilding an entire interoperability application manually.
