IFS Developer Studio - bugs

Suppose you have two components, A and B, and A depends dynamically on B, with an entry in deploy.ini as well. During deployment, B needs to be deployed before A. Since the deployment order of components is not predefined unless there is a static dependency between them, if A starts deploying before B has been deployed, you will get deployment errors if the conditional compilation is not set properly in the code.

we are trying to catch these type of scenarios beforehand at development time to avoid these errors.

CC ​@Jonas Feigl 

Suppose you have two components, A and B, and A depends dynamically on B, with an entry in deploy.ini as well. During deployment, B needs to be deployed before A. Since the deployment order of components is not predefined unless there is a static dependency between them, if A starts deploying before B has been deployed, you will get deployment errors if the conditional compilation is not set properly in the code.

our attempt was to identify these type of potential issues at the development time before they become deployment isssues

CC ​@Jonas Feigl 

​@InfFilipV 

• Conditional compilation is not just used for the solution sets but also plays a vital part in deployment order handling. Even if a component is enabled in the solutionset, it will still be treated as “inactive” during the delivery installation if that component is also included in the delivery, to avoid object dependency errors.
• @DynamicComponentDependency was deprecated as it was causing an unjustifiable amount of non-deterministic deployment issues: If a view is sometimes created and sometimes not based on the content of the delivery it makes the installation behaviour unpredictable as other views/packages that reference the view will then sometimes deploy successfully… and sometimes not. 
• Your example 4 is the exact approach that I would suggest for a large view with many different dynamic dependencies as it is still readable and avoids deployment issues.
• Regarding you final question how this can cause issues: Dynamically dependent components are not deployed in a specific order so you are not guaranteed that the objects of the referenced components actually exist and are valid at the point that the view is deployed. Example:
  • You have referenced Inventory_Part_API in your view
  • Inventory_Part_API, deployed via InventoryPart.api sits in the INVENT component.
  • As you seemingly do not have a static dependency from your component to the INVENT component you are not guaranteed that INVENT, and therefore Inventory_Part_API, will be deployed before your view is deployed.
  • There are now multiple scenarios where this can fail deployment of your file:
    • If something is included in the delivery that makes Inventory_Part_API temporarily invalid until the INVENT component is fully deployed, your view will fail deployment.
    • If the method in Inventory_Part_API you are referencing is also introduced from the delivery, your view will fail deployment. Of course in this particular case you know that this will not be the case because it is a Core method but we have to have a solution that works for all methods and not just for some.
    • If you are doing a Fresh Install of a new environment the Inventory_Part_API will not exist at all yet. Again, this might not be a scenario you are currently performing but again we have to ensure that the deployment works for all scenarios and eventualities. 
  • Therefore:
    • Adding conditional compilation around the call to Inventory_Part_API will ensure that the API call is not added to the view when both, the view and the INVENT component are included in a delivery. The view will then be redeployed later on in the installation process when all components have been deployed and the dynamic dependencies are guaranteed to be present.
    • Not allowing usage of @DynamicComponentDependency ensures that the view is still always created and any other objects that reference it are also guaranteed to deploy successfully.

The amount of support cases we receive because of deployment issues caused by unhandled dynamic dependencies (i.e. lack of conditional compilation) in modifications and the fact that even you, who seems to have an otherwise solid understanding of the process, are asking how this can cause deployment failures, kind of proofs the point why this check is now enforced.

I do understand your pain though and agree with your point that this should’ve come with better communication and ideally only be enabled for 26R1 onwards.

​@hamalk I don’t think it is a feasible approach to give developers the option to disable the alerts as that will completely counteract the goal of enabling them in the first place. Ideally I would suggest to review if we can disable the check for 25R2 and before to allow customers to address the alerts as part of the RU going to 26R1 or later and not being caught off guard half way through an implementation.

References for this topic

Dynamic Dependencies - Technical Documentation For IFS Cloud
Component Deployment Profile File - Technical Documentation For IFS Cloud
Entity Modeling - Technical Documentation For IFS Cloud
Components - Technical Documentation For IFS Cloud
Dynamic Calls to Optional Components - Technical Documentation For IFS Cloud

Upvote everything ​@Jonas Feigl puts out: Layer Support for deploy.ini | IFS Community
So, they don’t sit for 3 years.

Hi @Jonas Feigl,

thanks, this makes sense and I understand the reasoning.

When we develop the “Ext” layer, we of course follow this approach, because the delivery has to be clean, deterministic and reusable.

My point was mainly about the “Cust” layer, where we are usually working on top of already installed Core modules in a specific customer environment. In that context, we have so far often simplified this, because excessive conditional compilation can reduce readability and, in practice, also introduce new errors if it is not done correctly. (For example, in Core 25R2 reports, the do_sql_ variable is now set to TRUE only when the CRYSTL module is installed, which caused a few code blocks not to execute as expected.)

And realistically, this is exactly where the risk is: many developers will not implement the conditional compilation correctly, especially when they are fixing existing modifications in a hurry. I already wanted to find some ideal compromise - IFS - Backbone modules - Conditional compilation | IFS Community

So I fully agree that the check makes sense technically. My concern is mainly about introducing it suddenly for existing Cust projects, where there was often no previous pressure to handle these cases perfectly.

​@InfFilipV Developer Studio has analysis of the code for common mistakes in conditional compilation.

As an example, Oracle will raise an error if all of your code inside a method is inside a $IF/$END as it will say “method is empty”. Developer Studio will show you a warning telling you that you are missing a “$ELSE NULL;” section to avoid this. But there are other such warnings like when using a variable that is only available conditionally etc.

If you are aware of other such scenarios that currently do not show a warning in Developer Studio please report these.