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 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 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. 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
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. 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.
Hi, I'm working with @Mikko1234 on this problem, and I will also be active in this thread. 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. 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 s
Already have an account? Login
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.