Categories
Production to Test environment refresh impact on FDI
Hi Team,
Production to test environment refresh of source(ERP) application is going on and source application is not accessible. It has impacted FDI as well and we are not able to login to FDI/OAC. Is it the expected behavior. Our understanding was , we should able to login FDI/OAC. Once the ERP refresh is done, only full load is required to refresh the data. Is there any document which states the post refresh activities. The main concern is FDI unavailability.
https://docs.oracle.com/en/cloud/saas/analytics/24r2/fawag/reset-and-reload-data-source.html
Thanks
Best Answer
-
Hi @FDI_USER Is this FDI instance created as an integration with Fusion instance or it was created as a standalone instance? Can you please confirm?
Looking at the behavior it seems to me, you are using a Fusion integrated FDI instance. If that's the case then it could well be an expected behavior.
1
Answers
-
@FDI_USER - The P2T activity should not make FDI inaccessible; it is expected to remain available.
- Please check whether only login is failing or if FAW is completely down, even for users who were already logged in.
- If there are any specific error messages, please share them for further analysis.
- If FAW login depends on ERP authentication, verify the SSO or identity provider settings.
- If FAW is expected to be accessible but remains down, consider reviewing any maintenance notifications in OCI.
0 -
@Sumanth V -Oracle We are able to access ADW. However, FDI/OAC throws an error Oracle Cloud Fusion applications are undergoing scheduled maintenance. Seems FAW login depends on ERP authentication. SSO is not enabled in the system. Is there a way to remove dependency of ERP authentication ?
0 -
Hi FDI_USER, do you have an integrated FDI instance? We are currently assessing options for a new client and think this is a good point to consider if any maintenance activities at ERP end impacts availability of FDI (when FDI is integrated within ERP)
0 -
Hello @User_L2TQS
Thank you for raising this topic. We've implemented and configured FDI for several customers, using both the integrated FDI instance approach and the standalone FDI/OAC option. Based on our experience, I wanted to share some observations and recommendations, particularly for customers already running Fusion ERP.
For customers with an existing Fusion ERP environment, the recommended approach is to log in to the specific Non-Prod Fusion IDCS domain (e.g., DEV1 or DEV2, depending on your environment) and configure/install FDI within that domain. This ensures that user groups and policies are appropriately synchronized between Fusion ERP Non-Prod and FDI Non-Prod, enabling seamless integration and access control.
This setup has been reviewed and implemented successfully in collaboration with the CEAL team, @Dayne-Oracle @Krithika Raghavan-Oracle who also endorsed this approach. I’d suggest expanding this into a broader discussion around aligning FDI deployments with business user requirements, Architecture requirements especially in pre-production environments, to ensure that the correct Fusion ERP Non-Prod instance is selected and aligned with the appropriate OCI tenancy and IDCS configuration.
Hope this helps others planning similar deployments.
0 -
Hi @FDI_USER
To answer your question regarding whether a P2T (Production to Test) refresh impacts FDI logins, yes, it potentially can, and here are a few important points to consider:
One key recommendation is to verify whether the Fusion ERP user configured in the Non-Prod environment (used to set up the FDI pipelines) exists in the Production environment as well. After a P2T refresh, if the user doesn’t exist in Production or is overwritten, it could cause login or pipeline failures in FDI.
Additionally, it's crucial to confirm what type of user is being used for the FDI setup:
- Is it a local user created specifically for Non-Prod use?
- Or is it a Service Account with JWT Token authentication enabled?
This distinction is critical when configuring users for FDI pipelines, as JWT-based service accounts are more stable and secure for integration purposes—especially post-P2T refresh, where local users might get overwritten or lose privileges.
Always ensure the user’s existence and configuration are aligned between environments to avoid disruption after refreshes.
Hope this helps!
@Ashish-Oracle @Dayne-Oracle @Krithika Raghavan-Oracle @Benjamin Arnulf-Oracle - Any thoughts on the above ?
0
