Hi @Mikko1234 ,

I vaguely remember seeing an issue like this some time back and eventually found out that while the solution set file was read by the installer it was not able to parse it due to a syntax error. Probably worth checking if the solution set file has a weird character or something. 

cheers

Hi @Mikko1234 

Please refer to the following link for some details on how the solution set file works with set of components. 

When you install IFS Cloud, all components are installed, but only those listed as active (based on the chosen sales parts) in the solution set definition are enabled for use. The static component dependencies are still valid and must be followed, validation is done when building.

So all the components get installed but you can use only the active components in the solution set file. Database files get generated for all the components but client/projection files will get generated only for the active set of components in the solutionset file. 

http://techdocs/master/070_remote_deploy/030_patching_system/100_solution_set/

/Harshini

Thanks for the good suggestion, but this doesn’t seem to be the issue in our case.

 I compared the solutionset.yaml between our DEV (components are correct compared to the solution set) and TEST (all components are incorrectly active) environments, and the file is completely identical, and I didn’t find weird characters in the file.

It does feel like something similar would be the issue, since the installer says that the file is found and no errors happen during the installation.

@Mikko1234 

You will be able to access this link https://docs.ifs.com/techdocs/24r1/070_remote_deploy/030_patching_system/100_solution_set/

but not the link in my previous comments

Hi, I'm working with @Mikko1234  on this problem, and I will also be active in this thread.

Yes we do understand this. However, as stated earlier this is not the case in this installation.

In our development environment, which is created from same installation packages as the test environment, only the components listed as active in solutionset.yaml are active in IFS. But in our test development, all components are active, regardless of the solutionset.yaml. This means that even those components that are not part of the chosen sales parts are active in IFS.

Thank you for providing us the documentation. However, it does not really help in this situation. Based on the following text in the documentation:

When deploying, component status is set in module_tab and Conditional compilation is false for inactive components. All Post Installation files are touched and by that re-executed if the settings says so.

We created an SQL query to explain our situation further. When we run the script below in our development and test environments we get different counts. In development environment we get a correct count of 134 active components. In our test environment we get an count of 245 active components, i.e. all the components installed are also active.

SELECT COUNT(*) FROM ifsapp.MODULE_TAB WHERE ACTIVE = 'TRUE';

When compiling/generating a delivery containing the solutionset.yaml file, a file named ActivateComponents.sql will be created containing information about which components are set as true in the solutionset.yaml file.
When deploying this delivery to the database, the ActivateComponents.sql will first set all components to inactive and then activate components according to the information in solutionset.yaml file.

/Stefan

Thank you for your response.

 I have now checked the ActiveComponents.sql file from both environments, and it seems that it was created as an dummy template in both environments, since it only has comment lines. Surely this should not be the case? Yet in the development environment the components are correctly activated? 

Can the ActiveComponents.sql be modified and run manually, or does it have unwanted side effects? This would solve the problem for us.

When there is no solutionset.yaml in the root of delivery folder, a dummy sql file will be generated, because this file has to exist, will be called from install.tem. 
If you are looking at the <build_home> for these environment you will find the latest version of this file and that is probably why it is “empty”.
If you have deliveries saved for the development environment you probably will find one delivery containing your solutionset.yaml file.
The best way is to create a delivery containing the solutionset.yaml file. When compiling/generating, all post installation files will be touched, to be included in the delivery (can have affect on which components are active or not), code generator will generate client files… for all active components, and will be included in the delivery, and when running install.tem (deploying the delivery), there is a procedure that will be called to remove meta data for inactive components.

/Stefan 

So if I understood correctly, we should take a loot at ActiveComponents.sql inside build-home folder instead of ActiveComponents.sql inside the delivery folder?

In development environment  ActiveComponents.sql in build-home folder has multiple “Installation_SYS.Activate_Component(<component_name>)” rows, which seems logical, as the components are correctly activated there.

In test environment there are no “Installation_SYS.Activate_Component(<component_name>)” rows. ActiveComponents.sql in test environment looks same as the dummy file inside delivery folder.

Yes, we have ran the installer.cmd successfully multiple times. We have tried running it with two different ways: by just calling the script (./installer.cmd) and by defining the solutionset.yaml to be used (./installer.cmd --values .\solutionset.yaml). Both times CMD reported that solutionset.yaml is read and applied, yet the components are activated incorrectly.

It will not help in this scenario to add the solutionset.yaml to the installer. The file has to be in the delivery when the delivery is compiled to get the correct files to be deployed, and the ActivateComponents.sql created with needed information.
When then this delivery is deployed to the database, the files will be deployed including the ActivateComponents.sql file containing the information.

I am not sure I understand correctly what is meant here by  “compiling delivery”. But how is it possible that the file is not in the delivery when it is compiled? All files are in the paths where they were when I downloaded the latest delivery from the IFS lifecycle, including solutionset.yaml.

When a delivery is created, it will first contain only changed/new source files. This delivery will then be included in a build process, meaning that e.g. model and source files will be processed to generate the files that should be deployed, generated into the database folder. In the same build process the “extra” files be generated, merged files, install.tem, delveryregistration.sql, ActivateComponents.sql…