Handle optional component dependencies

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.

Make a customer feature build and behave predictably with an optional component both present and absent. This example uses fictional component OPTDEM; replace it with the actual component identity rather than creating a fake installed-component package.

Before you start

Use two supported development solution-set configurations, or equivalent clean test builds, plus access to the component’s deploy.ini and model sources. Record whether the feature can genuinely function without the dependency. If it cannot, it is a required dependency, not a dynamic one.

1. Inventory every reference

1. Find the optional component’s API calls, entity references, projection entities/actions, client fields/groups, and included fragments.
2. Record both the definition of each optional element and every place that refers to it.
3. Include SQL queries, generated reference validation, and deployment scripts in the review. A guard on a visible button does not protect an unconditional server dependency.
4. Define the absent-component behavior: hide the optional feature, return a documented unavailable result, or reject the operation with a meaningful error. Do not silently report success when required work was skipped.

2. Declare the deployment relationship

Add the actual dependency in the owning component’s deployment profile, preserving existing connections:

[Connections]
OPTDEM=DYNAMIC

This is a fragment. The build/installation framework uses the declared relationship when generating component availability packages. Do not manually change an installed component flag in production to simulate absence.

3. Guard model definitions and their uses

In client/projection models, use @DynamicComponentDependency on an optional definition and at its reference sites. For an optional fragment include, the pattern is:

@DynamicComponentDependency OPTDEM
include fragment COptionalHandover;

Also annotate uses of elements from that fragment. For example, if an optional group is defined inside it and placed on a page, review both the group’s definition and its page placement. Use the actual model’s declaration syntax; the include above is not a complete client.

For an entity reference, inspect whether the model supports the DynamicComponentReference code-generation property. Apply it to the actual reference and verify that generated validation is conditional. The property does not automatically guard arbitrary handwritten SQL or client references elsewhere.

4. Guard server calls at compile time

Use conditional compilation for known optional IFS components. This illustrative fragment belongs inside an existing method; the API name and signature must come from the real component:

$IF Component_OPTDEM_SYS.INSTALLED $THEN
   C_Optional_Handover_API.Validate_Reference(reference_);
$ELSE
   RAISE_APPLICATION_ERROR(-20010, 'Optional handover feature is unavailable');
$END

The error is a plain Oracle teaching example. In an IFS business method, use the appropriate translatable framework error and project convention. Keep conditional directives at the documented line boundary and ensure any optional parameter/record types are guarded too.

A runtime IF around a static API call still leaves a compile-time reference to that API. Replacing the call with string-built dynamic SQL solely to avoid declaring a dependency adds complexity and security review; it is not the preferred solution.

5. Generate and test both configurations

1. Build with the optional component enabled. Inspect generated model sections, server calls, and the visible feature.
2. Build the supported absent-component solution set from clean outputs. Inspect that no unguarded optional model/type/API references remain.
3. Verify the documented fallback or hidden feature. Existing unrelated functions must continue to work.
4. Re-enable the component through the supported build/install configuration and repeat the feature test.
5. Record both build identities, compilation results, and behavior in the review worksheet.

Expected result: both builds compile; the optional feature is usable only in the appropriate configuration, and callers get the agreed result when it is absent.

Troubleshooting

Symptom	Check
Missing Component_..._SYS	Correct deployment connection and generated installation artifacts
Absent build fails in a record type	Optional dependency in a declaration outside the guarded block
Client references a removed group	Reference site lacks the corresponding model annotation
Build passes but operation silently does nothing	Absent-component contract was never defined/tested

Exercise and solution

Exercise: the optional fragment is annotated, but a page still references its group unconditionally. What must change?

Show the solution

Apply the dependency annotation at the group’s reference site as well as its definition/include, then regenerate with the component absent. Verify that the remaining page is valid and useful. Do not make the optional component mandatory just to mask the missing guard.

Cleanup and delivery evidence

Restore the original development solution-set selection after testing. Deliver the deployment profile and all related model/server changes together. Retain both present/absent test results; do not hand-edit generated component packages as a release fix.

Sources

• Model dependency definitions and references
• Client/projection dynamic dependencies
• Conditional compilation and deployment connections
• Developer Studio solution sets and dependencies