Frequently asked Questions¶
What's the difference between EBR-enabled Base Server Framework and Delivery Continuity?¶
The Base Server Framework was uplifted to support Oracle EBR to allow the installation to change underlying database objects without affecting active users. This is the main concept behind Delivery Continuity.
To maintain consistency, all customers updating to IFS Cloud 25R2 or later needs to ensure that their code base is compliant with the new EBR-enabled Base Server Framework.
The Delivery Continuity features is built on top of this and is a optional additional step the customer can opt-in.
Therefore, there can be customers who have done the EBR upliftment but who does not enable Delivery Continuity .
Can I upgrade to IFS Cloud 25R2 or later without doing the Base Server Upliftment?¶
No, the Base Server Upliftment is a mandatory change that must be done when updating.
Do I need to take Delivery Continuity when I first update to a version later or equal to IFS Cloud 25R2?¶
No, you can first do the update with the mandatory EBR upliftment and then differ the Delivery Continuity activation work for later.
I have done the EBR upliftment, do I need to do anything more to my code when taking Delivery Continuity?¶
Yes, the EBR upliftment only puts the necessary foundation in becoming Delivery Continuity compliant. You will need to do further work before your code is Delivery Continuity compliant and you are able to do Online Deliveries. Further information can be found here
I do not have any customizations, do I need to do anything to my configurations when I update to IFS Cloud 25R2 or later?¶
No, if you do not have any customization changes, then you do not need to do the EBR upliftment. Uplifting of the core objects will be handled by the core update scripts.
The configurations are also handle by the core update.
I am planning to take Delivery Continuity, what's the suggested approach in enabling this?¶
Note: Delivery Continuity is currently in a controlled rollout, therefore please contact IFS before proceeding.
If you have a lot of complex customizations specially customized entities (you have created your own customized entities), then you may first do the EBR upliftment and after successful completion, move on to uplifting your code to be Delivery Continuity complaint.
If you have simple customizations(only changes in PL/SQL code, or few straightforward customized entities) then you may do both the EBR upliftment and the Delivery Continuity activation and upliftment at the same time. However, as the first steps, remove any obsolete customization. There after following the information here.
Once I have enabled Delivery Continuity can I do development in a non compliant way?¶
No, Once you have done the Delivery Continuity upliftment, you are not allowed to commit code that are non-compliant.
Can I do offline deliveries even if I have Delivery Continuity Enabled?¶
Yes, you can do offline deliveries even if Delivery Continuity is enabled. However, your code will still need to be Delivery Continuity complaint.
Do I need to use ddlsource and dmlsource files even if I am not using Delivery Continuity?¶
No, you are not required to use ddlsource and dmlsource files if you have not enabled Delivery Continuity. You can continue to use CDBs and the previous way of coding. However keep in mind that you will still need to adhere to the EBR-enabled Base Server standard.
I have not enabled Delivery Continuity but I am getting errors saying that I can't use CDBs¶
If you have not activated Delivery Continuity, you are allowed to continue using cdb files.
This is actually a misleading log entry. Eventhough log entry says that these are errors, they do not cause the build/delivery to fail. This is a known issue and is planned to be fixed with IFS Cloud 25R2 SU4.
The actual error might be something else, including EBR compliance failure which can be located in the \_ebr\_compliance.log inside the deploy_db/database_cleanup_\<timestamp\> folder.
If you got the failure in the Build Place, the easiest way to determine where it failed is by looking at the log folders. If you see a deploy_db folder, then it means that the delivery had continued to the deploy phase, if so check the IfsInstallerLogger.log inside the deploy_db folder.
If you don't see a deploy_db folder then the delivery had failed in build stage, therefore check the ifs_build.log inside the code_generation folder and navigate from there to step it had failed and the relevant log file.
If the issue was in Use Place then it's not a issue at the build step, but rather the deploy step. Therefore check the installer logs.
Do I need to call Database_SYS.Prepare_Table_For_EBR for core tables(delivered from RnD) I have customized?¶
No, the core entities/tables are uplifted via the core code, even if you have customized the core entities, they will be uplifted via the core update code.
I have fully customized entities (not existing in core) , where do I do the EBR upliftment?¶
This depends on how to are planning to take Delivery Continuity.
If you are doing the EBR upliftment first, then you can use the .cdb files. You can either
- Add the
Database_SYS.Prepare_Table_For_EBRat the end of each.cdbthat is defining the entities - Or add a common
.cdbwhich does the preparation for all the relavent entities.
If you are doing the EBR upliftment and the Delivery Continuity upliftment at the same time, then you can't use cdb files, therefore you need to use the upg files and also empty the existing cdb files.
If you have added these entities in a core module, then you can do this via the
2520-cust.upg. Ensure that the deploy.ini of that component has mentioned2520.upgfor the 25R2 update.If you have added these in a customized module (not core module e.g. CMOD), then you can do this via the
2520-cust.upg, ensure that the deploy.ini is correctly updated so that the UPG runs during update.
More information can be found here.
I am getting errors during the delivery deployment, but I didn't get any errors in IFS Developer Studio¶
There are certain things which can only be accurately caught during the delivery deployment or the delivery build. Therefore even though Developer Studio might not flag any errors, they might get flagged during the delivery.
I am having tables in my production database but they are not there in my source code, do I need to make them EBR compliant also?¶
As of now EBR compliancy is not enforced in the Use Pace environments. The compliancy check is executed and the non-compliant objects are logged and can be found in the delivery logs
However, these checks may be enforced (trigger errors) in the Use Place environments if a requirement comes. Therefore, it is advised to make sure that these tables are properly modelled as entities or if these are old tables created for backup purposes, then they should be obsoleted.
Why are some columns missing in the Editioning View (_TAB) but are there in actual table (_RTB)?¶
This can be because the entity mode or table definition in the storage file is not correct and missing the relevant columns. Therefore, when the Edition view is generated these columns are not added. Always ensure that the entity definitions align with table.
Note: You may have columns which are obsolete in the table, but any in use column must be covered in the definition.
I'm getting a deployment error towards the end of the delivery saying a column is missing in the editioning view, but it was there early on in the installation¶
This can be due to your model definition of the table missing columns. During the EBR upliftment, we create a temporary Edition View which is based on the actual table, therefore any column in the table will be there in the editioning view. However, this gets replaced with the editioning view created based model when the .edv related to the entity gets deployed. Now, if the model is incorrect, then this editioning view will not have all the required columns, thus causing deployment errors or invalids towards the end of the deployment.
Can I refer to tables (_RTB) directly in my code?¶
No, you should not directly refer to the real table name, this is true for logic and during the creation and alteration of it. Since the actual table name may change overtime due to things like staging (relevant for few tables), referring to the table may lead to errors. If you want to get the table name any reason, you must use the methods Database_SYS.Get_Or_Generate_Rtb_Name if you are creating the table or Database_SYS.Get_Rtb_Name if the table already exists. If you are using these methods as Delivery Continuity customers in a ddlsource or dmlsource file, then you should use methods which end in #. Database_SYS.Get_Or_Generate_Rtb_Name# or Database_SYS.Get_Rtb_Name#
Also, since logic written in PL/SQL code are edition-able, and tables are non edition-able this referencing will lead to errors if the table is changed. This is why such references are caught as EBR compliance issues. If you want to get the real table name you can use Database_SYS.Get_Rtb_Name in the logic.
How can I test Online Deliveries?¶
There are three stages Online Deliveries are tested.
The first happens in the build stage, here, the written code is validated for compliance. This is more of static code analysis ensure that the written logic is correct. However, we cannot accurately validate the runtime behavior with this.
Therefore, next, in the Use Place Non Production environments, the changes are validated with a deployment. Here, the actual end deployment state is validated ensuring that no schema changes were propagated to running application from the installation (e.g. the added column has not changed any other object that was in the running application version/edition, meaning the column addition was invisible to the running application).
However, this also only validated schema level changes, but we need to consider the data also. Therefore, it is recommended to validate the running application while the installation is ongoing. If you know areas the Delivery is touching, have test users using those areas while the delivery is been applied and ensure that no unwanted behavior occurs.