hi ​@jamie.malangyaon 

Do you use a solutionset file as well, Hopefully yes, then you need to include youe new component into the solutionset.yaml files as well and make it active

eg: ABCDE = true

also refer to

https://docs.ifs.com/techdocs/25r1/010_overview/030_logical_architecture/?h=component#components

: https://docs.ifs.com/techdocs/25r1/060_development/027_base_server_dev/030_mechanisms/040_dynamic_calls/

​@jamie.malangyaon 

before doing any code level changes you need introduce the custom component and do the changes in the deploy.ini files and the solutionset yaml and send those to a sanity build in a separate branch and get a successful Sanity build. After that only you should do the code level changes and trigger another sanity build. 

Hope this works for you 

thanks

Harshini 

Hi ​@hamalk,

Thanks for the reply! Just to confirm the steps:

1. In Branch1: Complete the create the custom component (include in the solutionset, set deploy.ini..etc.) and update the order component deploy.ini with the custom component to set it to Dynamic → Run a Sanity Build
2. In the same branch as the sanity build, do the code changes and order another sanity build.

If these are the steps then I did run a sanity build last night (only on the component changes) but I noticed that the COMPONENT_{our cust component}_SYS is still not created in build place DEV

2 questions:

1. I noticed that in the documentation, we can run a script to trick our build place DEV to create the COMPONENT_{our cust component}_SYS - should this be done somewhere between step 1 and 2?
2. After I merge branch1 into the master branch and run a sanity build on the master branch before creating a delivery - will the sanity error out since the sanity build would not have the custom component registered yet?

Hi ​@jamie.malangyaon

1. I noticed that in the documentation, we can run a script to trick our build place DEV to create the COMPONENT_{our cust component}_SYS - should this be done somewhere between step 1 and 2?  

Where was this mentioned ? 

1. After I merge branch1 into the master branch and run a sanity build on the master branch before creating a delivery - will the sanity error out since the sanity build would not have the custom component registered yet? Yes that could be the reason, Sanity build can fail with the code changes with the custom component is not registered. Therefore you need to created a separate branch first only the new component and necessary deply.ini and solutionset changes just to make sure the COMPONENT_{our cust component}_SYS is got registered before the code changes. 

Hi ​@hamalk,

For the first part - but I guess this would be necessary if I wanted to test the code changes before the deploy.ini changes get registered into our environment

I found this section in the documentation link that you shared: Dynamic Calls to Optional Components - Technical Documentation For IFS Cloud

For the second part - Ah I see, I guess the best route to make sure that I get a successful sanity and delivery for this scenario is to:

1. create the custom component and add the necessary deploy.ini changes in component order - get that delivered into our use place to trigger the creation of the COMPONENT_{our cust component}_SYS
2. Then I can add the code changes to the new build place DEV because COMPONENT_{our cust component}_SYS is created and the sanity should recognize it from the last delivery

​@jamie.malangyaon  please let me  know the outcome after trying out above. Then we can create a KBA for the benefit of others as well . :) 

​@hamalk I did not go along with trying out my last message because it would have taken too long to wait for a delivery to get the deploy.ini change installed.

My main concern was that the sanity or delivery creation would fail because the deploy.ini file with the dynamic dependency wasn’t installed since it hasn’t gone through a full build or delivery yet and my conditional compilation in my code changes in the same branch would create a “unknown identifier” error similar to what happened while working in the build place environment but it didn’t. I also didn’t need to create multiple sanity builds between changes in the deploy.ini and my code changes.

My steps developing in the build place with my scenario:

1. I updated the ORDER deploy.ini to include a dynamic dependency with my custom component
2. I manually registered the dynamic dependency into the build place environment so that the Component_{comp}_SYS package can be created. Template from  documentation:

   INSERT INTO module_dependency_tab  
   (module, dependent_module, dependency, rowversion)  
   VALUES  
   ('<TARGET COMPONENT>', '<DYNAMIC COMPONENT>', 'DYNAMIC', SYSDATE);  
   COMMIT;  
   BEGIN  
      Installation_SYS.Create_Component_Package(TRUE);  
   END;  
   /

3. I did my code changes in the same branch (no sanity build yet) and it included the conditional compilation IF statements (I no longer got the PLS-00201: Identifier COMPONENT_{our cust component}_SYS.INSTALLED…. error because of step 2)
4. The sanity builds on master branch(after merging the changes) and the delivery creation was successful.