Replies posted by Hiroshi Perera
@xitshifar : As Dinnushi mentioned this issue should have got corrected after uplifting the environments to UPD12 level, since the R&D fix for the issue gets applied during the UPD6 level. Are you receiving this error before uplifting the environments to the UPD12 level, and when the environment is in UPD4 level?
Hi @Matthew,Open normal Excel Application and then manually load the BA Add-in into Excel, please see below screen shots for the detailed steps.Step 1: Open Excel Application with a Blank Work BookStep 2: Go to File-> Options as shown belowStep 3: Go to Add-Ins Window and then under Manage Combo Box Select Com Add-ins and Click Go as shown belowStep 4: Check the IFS Business Analytics Add-in and Click ok (If the add-in was already checked uncheck click ok and then again check it and click ok)Step 5: Close Excel and try to open the BA Client to see if the error is resolved once the add-in was manually addedIf the above doesn’t solve the issue, then please check if any new add-ins were installed recently as this could cause issues with the BA Add-in. If there are any, please try to disable these temporarily then see if the BACL works.
Hi @anuruddhabm, A 404 error usually occurs when the relevant deployment in Middleware Server is not active. Try to login to IFS Middleware Server Admin Console and from the “Deployments” tab, check whether all the deployments are active. Since you are getting the 404 error at login, it has to be the ifsapp deployment. You can start/stop deployments as well from this console. Try to start inactive deployments. IFS MWS Console’s deployments view in IFSAPP9If that doesn’t work, you can do the following. Login to the Application Server host machine and go to following folder in your IFS Home: \\<IFS_HOME>\instance\<InstanceID>\ear\ Delete the .ear and .war files in above directory. Run the installer.cmd and do a reconfiguration. During the reconfiguration, above .ear and .war files will be repackaged and redeployed to the Middleware Server. Once the reconfiguration is finished, make sure all the servers are started and see whether you are able to login. Hope this helps! Hi
Hi…Yes we usually refresh Reference Cache after you have deployed any view (package) which changes the reference information about the LU's. The Reference cache manages data needed for checking of referential integrity. The Reference cache is used any time you remove data in any client. Regards,Hiroshi
Hi Kalana,During a recent UPD12 installation, I received same type of an error. !!!Error deploying file install.tem at 24-SEP-21 12:39:14!!!Error occurred while executing Plsql BlockBEGIN Object_Connection_SYS.Refresh_Active_List__(5);END;ORA-20105: Assert.IS_LOGICAL_UNIT: "DocumentContainer" is non existing logical unit.ORA-06512: at "IFSAPP.ERROR_SYS", line 140ORA-06512: at "IFSAPP.ERROR_SYS", line 341ORA-06512: at "IFSAPP.ASSERT_SYS", line 844ORA-06512: at "IFSAPP.OBJECT_CONNECTION_SYS", line 146ORA-06512: at "IFSAPP.OBJECT_CONNECTION_SYS", line 1947ORA-06512: at "IFSAPP.OBJECT_CONNECTION_SYS", line 1947ORA-06512: at "IFSAPP.OBJECT_CONNECTION_SYS", line 1621ORA-06512: at line 2 When checked it in object connections window, this is how it looked, The issue is, it is existing in all the customer internal environments as well. So, the same error will be appeared in customer internal environments as well. Also, I didn’t notice a script or anything that had added this. Also this doesn’t
@Nimasz : Yes I too believe that it is a good option. In addition to that, incase if you take the backup of the Database at the very beginning, there is a high probability to get it deleted since the complete apply update process usually takes longer than 5 days. But in addition, if we can take the database backup before the UPD installation get started, then there might be a good chance that we could end the UPD process within 5 days. This not a very reliable option, because it has risks as well (If someone changes the database accidently during the apply update process, then we do not have a way to recover the DB). But we can give this option a try too..
Hi @CUCSOLUTIONS There could be several entries under the <HOME_LIST> tag because, it seems you have several IFS_HOME instances in your environment. But make sure, REMOVE=”T” is not inside any instances, listed under tag <HOME_IDX ….>.Incase if you have stopped all the servers, make sure node_manager and adminserver are running :)
Hi @CUCSOLUTIONS,Well, regarding the following question you asked, On item #3 - how do you know if this file is corrupted? I do see references there to old environments, but existing environment entries look good. Following is an example of a healthy inventory.xml file.If this is corrupted, the <HOME_LIST> will not be appear according to the above format and most probably at the end of <HOME_IDX tag of the corrupted IFS_HOME instance, there will be an additional REMOVE=”T” tag. So to run the installation in a healthy manner, you can replace it with the backups which is in path ex: C:\Program Files\Oracle\Inventory\backup.
Following URL seems as a useful resource to take the database backup using RMAN. It is taken from the official Oracle website.https://docs.oracle.com/cd/E11882_01/backup.112/e10642/rcmquick.htm#BRADV90059It is always better and safe to try this in a test environment first.
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.