A scheduled SQL job or public API is production infrastructure — yet many teams change them like personal spreadsheets: no ticket, no peer review, no rollback plan.
iDataEngine centralizes REP designs, SQL projects, API services, MF templates, and AccessGuard scans in one web cockpit. Governance means applying change control to those artifacts, not exporting them to shadow IT.
What to treat as a controlled change
- SQL project — method, delta parameter, connection, or schedule change
- API service — fixed filter, fieldset, URL extension, security limits, active flag
- REP iView — new fields, join changes, activation after save
- AccessGuard — SoD rule edits, custom scan definitions
- BI objects — publish, role assignment, cache refresh jobs
The platform supports evidence: application logs, service logs, job monitor history, API monitor, AccessGuard snapshots, and request logs. Use them as your audit trail instead of e-mail threads.
A lightweight change-control pattern
- Open a change ticket referencing the object ID (project name, service name, iView ID)
- Test in non-production (Test Service, SQL Test, iView Test)
- Save during an approved window — API URLs refresh on every save; communicate new GUIDs
- Capture an AccessGuard or job-monitor baseline snapshot after go-live
- Define rollback: deactivate API, disable job, or restore prior iView version from transport
Why it matters
Speed without change discipline creates "works in prod until it doesn't" integrations. When cockpit configuration is versioned, tested, and tied to snapshots, you keep the low-code advantage without losing enterprise rigor. Governance here is not bureaucracy — it is how you make innovation repeatable for the next hundred APIs and jobs, not just the first.