Where every IFS Developer Studio habit's job now lives — the component tree and marble files to the Application Object Tree, .ins deliveries to Git and deployable packages, EXPLAIN PLAN/AWR/TKPROF to Trace Parser and Query Store — and an honest account of where the Oracle toolchain is still sharper.
Every IFS developer carries a mental map that is really a map of jobs to be done: IFS Developer Studio to browse and edit, a SQL client to look directly at the data, Solution Manager to package a delivery, the PL/SQL debugger and dbms_profiler when something is slow or wrong. None of those jobs disappear on D365 F&O.
IFS Developer Studio's promise is a single environment: browse the component tree down to a Logical Unit, open its PL/SQL, edit its projection, and deploy — largely without leaving the tool.
An IFS component groups a set of related Logical Units; each LU compiles from a marble (model) file into a generated PL/SQL package, a database table, projection metadata and Aurena binding, all addressed as one object.
IFS domains constrain a column to a named, reusable set of allowed values or a semantic type (a numeric domain, a percentage, a date). IFS enumerations do the same for a fixed list of named states. Both map cleanly:
Chapter 1 covered the general shape of the extension model and the no-overlayering rule. This section is about where you go, tool by tool, to actually build each IFS customisation surface — and where one has no clean landing at all.
An IFS delivery is typically staged and applied as a .ins script bundle, assembled at a build home and promoted between environments by a IFS Solution Manager–coordinated move. It is a scripted, often hand-assembled artefact, and the traceability of what changed lives largely in the delivery notes and the script itself.
A typical IFS estate gives developers real freedom over the Oracle database: a shared development instance, direct SQL access, and — for many shops — the ability to refresh a lower environment from production, or even to move data upward when a specific test case demands it.
DBMS_OUTPUT, the PL/SQL debugger and dbms_profiler are the day-to-day Oracle diagnostic set: print statements for quick checks, breakpoints and step-through for logic errors, and line-level timing for a slow procedure. Each has a rough D365 counterpart, with one gap.
Best-practice checks run automatically on every build, catching naming, layering and pattern violations before a package can be deployed — the rule-based-static-analysis role that IFS coding standards and generated-code discipline fill through convention and code review.
The IFS developer's local loop is Oracle-centred: PL/SQL package work, SQL Developer, EXPLAIN PLAN, AWR/TKPROF, ROWNUM probes, Connect Monitoring and Solution Manager deliveries. The D365 local loop is AOS-centred: Visual Studio opens the model, the local AOS runs the web application, and the browser is the test client.
The tools change shape more than they change purpose. Every job an IFS developer does daily — browse metadata, write and debug code, package a change, promote it, and diagnose a slow query — still has a home in D365.