Inforgl ↔ OneStream over REST, with a shared-script library
Quick Facts
- Industry: Manufacturing
- Role: Integration Lead
- Impact: Inforgl GL feed pulled into OneStream over a direct REST connection; member-formula and confirmation-rule logic consolidated into a shared backend script; report formatting standardised through shared parameters so every report comes out consistent.
Overview
The client ran their general ledger in Inforgl and their consolidation and reporting in OneStream. I built a direct Inforgl → OneStream connection over REST to bring the GL data across, then used the engagement to fix two things that make a OneStream application hard to live with: member-formula and confirmation-rule logic written separately on every member, and report formatting done by hand on every report. The integration was the visible deliverable; the shared-script architecture and the shared formatting parameters were the durable ones.
The Integration
This followed the same pattern as a direct REST API connection: rather than exporting files, a connector business rule calls Inforgl's REST API and brings the GL data into OneStream's load process, and the whole thing is automated with an Extensibility rule so it runs without an analyst exporting and reshaping a file each period. No file in the loop, no manual hop.
The Shared-Script Architecture
The default way to write a member formula is to put it directly on the member. Do that across an application and it becomes a nightmare to manage — the same logic ends up written in many places, and changing it means hunting down every copy.
Instead, I moved the logic into a shared script (a backend business rule) that holds the member formulas as functions, and each member simply references the function. That means:
- One place to maintain. A rule change happens in the shared script, not on dozens of members.
- Shared objects and functions become possible. Logic can be reused and composed across members in ways you simply can't when each formula is trapped on its own member.
- The same approach applies to confirmation rules — the common checks live in the shared script and are referenced where they're needed, rather than re-written per workflow.
Standardised Report Formatting
Rather than formatting each report individually, I created shared parameters — a default header parameter and a default cell parameter — that you attach to a cube view (what OneStream calls a report). Once attached, the report inherits the standard formatting, so headers and cells look consistent throughout the system instead of drifting from one consultant's report to the next.
Results
| Metric | Before | After | Change |
|---|---|---|---|
| Inforgl → OneStream feed | manual export + reshape each period | direct REST pull, automated | manual hop retired |
| Member-formula / confirmation-rule logic | written on each member, copied across rules | shared backend script of referenced functions | one place to maintain |
| Report formatting | done by hand per report, drifted between consultants | shared header + cell parameters attached to the report | consistent system-wide |
Learnings
What worked. Treating the shared script as the real win. Member formulas on the member are the default, but they don't scale — moving the logic into a shared business rule and referencing it turns a maintenance nightmare into a single source of truth, and unlocks shared functions you couldn't otherwise use.
Skill developed. Building OneStream applications for the team that inherits them, not just for the demo — shared scripts for logic and shared parameters for formatting both come from the same instinct: define a thing once, reference it everywhere.