Name and layer an IFS customization

Development and modifications

26R1 reference · Documentation-based walkthrough · Sources reviewed 2026-09-28 · Not executed in IFS or Oracle. Match the database, build home, and tools to your installed release. Example names are fictional.

Create a naming and ownership map before adding a handover-reference field or service. The result should show which files you own, which contracts you extend, and which generated artifacts must remain reproducible.

Before you start

Use an authorized development checkout and matching Developer Studio project. Record the actual component, parent entity, projection, and client in the review worksheet. Start with the persistent-field example if you need a complete model-to-page walkthrough.

1. Decide whether this is configuration or source customization

1. Write the required behavior: an authorized user saves a handover reference and later reads it through the supported page/API.
2. Check whether a standard field or configured attribute already meets that need.
3. Use a Cust-layer modification only when the requirement needs a source change. Identify whether you are creating a new customer-owned object or extending an existing Core object.
4. Find any existing Cust file before creating another. Keep unrelated customizations intact.

2. Name the owning object before its members

Use this original naming worksheet; the exact generated database spelling comes from your model/toolchain.

Situation	Example	Reason
New integration projection	CHandoverReferenceService	Customer-owned service identity
Operation inside that new projection	NormalizeReference	No redundant C prefix required for each member of the new C-prefixed projection
Added attribute on an existing Core entity/projection	CExternalReference	Distinguishes the addition from inherited fields
Entity and collection in the new projection	HandoverReference / HandoverReferences	Singular object, plural entity set
Added navigator entry	CHandoverNavEntry	Clear customer ownership and documented entry suffix
Added group in an existing client	CHandoverGroup	Identifies a new customer element

Do not rename an inherited field or group merely to add a prefix: overrides must still target the original declaration. Entity sets should normally use plural nouns; a Set suffix is useful where singular/plural would otherwise be indistinguishable. A team’s additional convention is a project rule, not automatically a universal IFS rule.

For a fictional entity CHandoverReference, inspect the generated database object map: a storage table such as C_HANDOVER_REFERENCE_TAB, its supported view C_HANDOVER_REFERENCE, and package C_HANDOVER_REFERENCE_API. The table stores rows, the view provides the intended read contract, and the API supplies business operations. Confirm the exact generated names in Developer Studio; do not create lookalike objects by hand or assume the base table enforces the view/API’s security.

3. Keep method visibility separate from naming ownership

IFS server method conventions use trailing underscores to express intended scope:

Pattern	Intended use
Get_Reference	Public interface
Get_Reference_	Protected interface within the owning component
Get_Reference__	Private entity-level interface, often used by framework/client services
Get_Reference___	Implementation detail within the architecture layer

These are framework conventions, not a replacement for grants or generated security checks. A method’s accessibility in an Oracle package specification is a separate consideration. Do not make an external integration depend on an internal implementation method because its name is visible in a checkout.

For new server methods added to a standard API, follow the customer prefix convention (C_...). A new customer-owned API does not necessarily require the same prefix again on every member. Confirm the generated contract and existing project conventions before renaming an established method.

4. Create the smallest supported Cust change

1. Open the parent model in the build home; use Customize This where supported for projections and clients.
2. Keep the generated Cust header and add only the required declarations.
3. Prefer an override that retains inherited behavior where the model supports it. Use an overtake only after reviewing what must be repeated and maintained.
4. Follow includes and fragments. An element may be owned elsewhere even when it appears on the current page.
5. Save and inspect the diff. Generated SQL/package output is evidence to inspect, not an alternative source file to patch by hand.

For a new service, follow the projection function procedure. A filename convention alone does not create a callable implementation.

5. Generate and check compatibility

Generate with the matching target version. Review the merged model and generated contract, then confirm:

• inherited fields/actions remain present;
• the new name does not collide with another layer;
• callers still see existing parameter and return names;
• only intended files and dependencies enter the build;
• update-analysis findings are reviewed after a parent-release change.

Record source revision, generated names, and affected consumers in the worksheet. A successful build does not establish permission or business behavior.

Troubleshooting

Symptom	Next check
Override cannot find its target	Actual parent name, owning fragment, build home, and release
Existing fields disappear	Replaced declarations or overtake scope in the merged model
Client compiles but endpoint differs	Projection identity and generated contract, not the client filename
Naming review is inconsistent	Separate vendor convention, team preference, and established public contract

Exercise and solution

Exercise: add a customer field to an existing entity and an operation inside a new C-prefixed projection. Should both receive the same extra prefix?

Show the solution

Use a distinguishing customer name such as CExternalReference for the added Core member. An operation inside the new customer-owned projection can be NormalizeReference. Preserve inherited identifiers, and confirm server-method naming separately from projection element naming.

Cleanup and delivery evidence

Discard only the exercise’s source changes if they are not being delivered. If already deployed, use a reviewed reversal through the build process; a persistent column may contain data. Retain the object map and API compatibility checks for code review.

Sources

• Customization naming and syntax
• Client and projection syntax
• Method protection conventions