Migrating from Cognos
Rynko can read IBM Cognos artefacts directly and turn them into Rynko objects you can edit. There are two importers, aimed at the two halves of a Cognos estate.
Two import paths​
Import from Cognos — the model​
Reporting → Import from Cognos takes a Framework Manager package — a deployment .zip, or a model .dat or .xml — and produces query objects.
The importer parses the package, finds its query subjects, and shows you a preview of what it would create. You choose which subjects to import; each becomes a Rynko query object with its SQL and its parameters.
Do this first. It gives your reports something to sit on.
Import Cognos Report — the reports​
Reporting → Import Cognos Report takes a report specification XML and produces a complete report: the query objects it needs, a Rynko template reproducing the layout, and the report definition linking them.
What is translated​
| Cognos concept | Becomes |
|---|---|
| Native SQL query | A query object with the SQL preserved |
| Query subject | A query object |
| Prompt | A typed report parameter |
| Detail filter | A parameterised WHERE clause using :param placeholders |
| List / table | A data table in the template |
| Page layout | A grid component with cells, merges, and borders |
| Running totals, group subtotals, column aggregates | The equivalent report table features |
IF / CASE data items | Calculated columns |
| Conditional formatting expressions | Template conditional styling |
Prompt macros translate too: ?PARAM? becomes :PARAM, and a Cognos in_range prompt becomes BETWEEN :PARAM_start AND :PARAM_end.
Choosing an output format​
At import you pick whether the report targets Excel, PDF, or both. This matters more than it sounds: a Cognos list rendered for print and the same list rendered as a working spreadsheet want different column widths and different row heights, and the importer calibrates for the target you choose.
Calibrating against a sample output​
The report importer optionally accepts a sample output workbook — an .xlsx that Cognos actually produced for the report you are importing.
Supply one and the importer treats it as ground truth for presentation: column widths, row heights, and band alignment are calibrated against the real output rather than inferred from the specification. This is the difference between a report that is recognisably the same document and one that merely contains the same numbers.
If you have the sample, use it. It is the single highest-leverage thing you can do for import fidelity.
What it publishes​
A committed import creates the query objects, creates and publishes the template's initial version, and creates the report. You land on something you can run, not a draft you have to assemble.
What needs a human​
The importer is best-effort on expressions, and it tells you where it fell short rather than silently guessing:
- Untranslatable aggregates are flagged as warnings on the import, not treated as fatal. The rest of the report still imports.
- Complex conditional expressions may need adjusting in the expression builder.
- Cross-query arithmetic is derived where the relationship is inferable and flagged where it is not.
- Cognos functions with no Rynko equivalent are reported so you can rewrite them.
Read the warnings after every import. They are the list of things to check before you trust the output.
A workable order​
- Import the model to create query objects, and test each one against your datasource.
- Import reports one at a time, starting with a simple one to calibrate your expectations.
- Supply sample outputs wherever you have them.
- Compare the Rynko output against the Cognos output for the same parameters. Numbers first, then layout.
- Fix the warnings.
- Schedule the report, and run both systems in parallel for a cycle before switching off the Cognos schedule.
After the import​
Everything the importer produces is an ordinary Rynko object. The template opens in the visual designer, the SQL opens in the query editor, the parameters are editable. There is no import-only format and nothing is locked — the point of the importer is to get you to a starting position, not to hold your reports in a translation layer.