Lifecycle Experience Portal Troubleshooting Issues¶
Overview¶
This section describes some common Lifecycle Experience issues and the steps that can be followed to resolve those issues.
ALE Portal Error Codes¶
There will be instances where user gets two types of error toasts;
-
Error message with a specific code (Refer to Figure 1.1)
Figure 1.1 - Sample Error Message with an Error Code -
Error message only (Refer to Figure 1.2)
Figure 1.2 - Sample Error Message without an Error Code The reason for above is because the ALE Portal Error Handling Framework is an ongoing development and the error codes will continuously improve and grow as the framework is improved.
When an error toast is displayed, a support ticket must be created with a screenshot of the same. This will help the IFS Support teams receive more descriptive support issues and will make the troubleshooting much easier.
Cannot login to IFS Lifecycle Experience Portal¶
-
This can happen due to a browser caching issue. To verify that open the browser in incognito mode (Shortcut for Chrome is Ctrl + Shift + N) and try to login again.
-
Contact IFS support and check whether the user account exist in IFS Azure Active Directory (using Azure portal). If user account does not exist it is a issue with identity management. Should contact COS to rectify the issue.
- Contact IFS Support If the portal cannot be accessed even though the user account is properly created
Cannot see the buildplace in IFS Lifecycle Experience portal¶
- Check whether the user exist the correct Active Directory group (For more information on Active Directory groups refer User Authorization of the System). Got to Azure portal > Azure Active Directory > Groups > Search for the groups of the buildplace by typing the 'ale ' and buildplace name. Select the relevant group and check the members of the group. If the user does not exist in the correct group contact one of the Owners in the relevant group to get the user added to the required group.
- If you do not have the sufficient permission to view the Active Directory group contantact IFS support to perform the above action.
- Contact IFS Support if the buildplace is not visible even though the user is added to the correct Active Directory group
Cannot access the buildplace repositories¶
- Check whether user is added in to a Active Directory group which has rights to access the repositories. Refer User Authorization of the System for more information.
- If the user cannot access the repositories even though the user is added to the correct user group create a support issue and contact IFS Support Note: When a user is newly added to a Active dirictory group, in some occasions, "Re-Evaluation of Group rules" needed in order to have proper Azure DevOps organization access to the user.
Error when ordering an environment¶
-
If the network share is accessible check the logs to identify whether it is a compilation error or a deplyment error. If so resolve the issue in the source code and reorder the environment
-
If it is not a compilation error or a deplyment error, go to jobs in IFS Lifecycle Experience portal. Find the relavent job for the environment ordering request.
- Go to the pipeline URL and check the 'Execute Buildplace action' to find the error.
- If the error cannot be self rectified create a support issue contact IFS Support. Copy the pipeline log content to a text file and attach to the support issue. Attach the logs avalable in network share also to the support issue if the network share is accessible.
Error when applying service update¶
- Check the pipeline log as described in the Error when ordering an environment section
- If the error cannot be self rectified create a support issue contact IFS Support. Copy the pipeline log content to a text file and attach to the support issue.
Known issues when applying service update deliveries¶
- PLS-00907: cannot load library unit CUSTORD_SUPPLY_DEMAND (referenced by CUSTORD_SUPPLY_DEMAND) error at line no:0
This issue has been noticed when updating from service update 21.1E.0 to 21.1E.1.
If the error log states the above issue, please re-run the delivery deployment/ sanity build.
- PLS-00907: cannot load library unit CONFIG_EVALUATION_API (referenced by CONFIG_EVALUATION_API) error at line no:0
This issue has been noticed when updating from service update 21.1E.1 to 21.1E.2
Please re-run the delivery deployment/ sanity build if this error is present in the log.
Cannot connect to the VPN¶
-
Verify whether the correct username and password is used
-
Check whether background apps are enabled and Azure VPN Client is enabled to be run as a background app in windows settings
-
Run the command "ipconfig /flushdns" in a command prompt console. This may help to resolve the issue if it is related to cached DNS entries.
-
If the above steps doesn't resolve the issue create a support issue contact IFS Support. Attach a screenshot of the error message to the Cloud Deployment team.
-
Check whether the Active directory group is correctly added to the service principal user. First find the Application ID of the service principal user from Azure portal > Resource Groups > ale-'buildplace name'-rg > ale-'buildplace name'-vnet-gw > Point-to-site configuration. Copy the Application ID from Audience field.
- Find the name of the service principal user from App registrations.
- Check whether the Active Directory groups are added from Enterprise applications > 'service principal user name' > Users and groups. Search for the Active Directory groups of the buildplace by typing 'ale buildplace_name'
Add the Active Directory groups if not added properly. Note: authentication for nested AD groups will not work here. It is the current limitation in the solution. E.g.: Suppose there are 2 AD groups called A, B and there are members in both of them. If group B is added as a member to A and only Group A is added to the VPN configuration, only users listed as direct members of group A will be granted access. Due to the above mentioned nested group limitation users of Group B will not be authenticated.
- Check whether there is some issue with the VPN gateway of the buildplace using Azure portal. Go to Resource Groups > ale-'buildplace name'-rg > ale-'buildplace name'-vnet-gw > Resource health.
Cannot access or cannot login build place environment - IFS Cloud¶
- In case of application is not accessible, check whether its possible to login to the database and whether its possible to access the network share. If those are also not accessible stop the environment and start again. Check whether application can be accessed after restarting the environment
- In case of not possible to login to the application or application is not accessible even after restarting, delete the environment and reorder. If environment reordering is success but issue still exist create a support issue and contact IFS Support
- If the environment reordering fails follow the steps in Error when ordering an environment section
Cannot login to the database¶
- Check whether you are connected to the VPN. If not connect to the VPN and try again to connect the database.
- Check whether there are compilation errors or deployment errors using the logs available in the network share. If so resolve the issue in the source code and reorder the environment
- If there are no compilation errors or deployment errors and still cannot login to the database contact the technician
- If the issue cannot be rectified with the support of technician create a support issue and contact IFS Support
Artifacts are not available in storage (Sanity logs, Deliveries, etc.)¶
- Check the pipeline log for the relevant job as described in the Error when ordering an environment section
- If the issue is in source code resolve the issue in source code and redo the task
- If issue still exist follow the steps related to the task (e.g.: If sanity logs are not available follow the steps in Error in sanity build)
Error in sanity build¶
-
From the storage window find the logs and check whether there are compilation errors or database deplyment errors. If so resolve the issue in the source code and reorder a sanity build
-
If there are no compilation errors or database deployment errors check whether reodering a sanity build solve the issue.
-
Check the pipeline logs. Go to jobs in IFS Lifecycle Experience portal. Find the relavent jobs for the sanity ordering (There shoud be two jobs one having the type sanity-pipeline and one having the type sanity-image. sanity-pipeline type job invoke the sanity-image type job to run the sanity build). Click the pipeline URL to see whether there are errors in the pipeline log.
Create a support issue to be investigated by cloud team IFS Coud Operations team. Copy the log content to a text file and attach to the support issue.
CDB files not deployed¶
- If CDB files are not deployed, it could be that the module is installing as a "fresh install". In a "fresh install", CDB files are not deployed.
- Incorrect module version registered in the database can cause this behaviour. Verify whether the module is registered by any database script. Eg:
- If the module is registered by a script, remove the registration code block / file or set the version to the correct value as in deploy.ini (only if it cannot be removed).
- Run a new Sanity Build to reflect the correct module version and the CDB files needed to be committed again to deploy them correctly.
View Logs¶
While in operation, users have access to logs which would enable the detail view of the process.
Automation related logs can be downloaded from the logs page.
Available log types :
- Sanity build logs
- Environment build logs
- Build Delivery Logs
- Deployment Delivery Logs
- Release Update Logs (Only available inside the RU Studio Logs view)
Buildplace Logs¶
Logs related to "Buildplace" are here.
By default, the build place logs will be shown in a collapsed view as shown below.
Once you expand a section of the logs view, the logs will be listed in a descending order with the lateset log placed on top.
Release Studio Logs¶
Logs related to "Release Studio" are here.
Error Logs¶
- Error logs are shown in red color text [1]. The download icon [2] can be clicked to download the logs as a zip file.
- The zip file includes multiple folders and the user can go through the text file "fetch.log" to view the log content.
Troubleshooting with the Job ID¶
Each operation (job) performed via the Build Place or Release Update Studio includes a unique ID called the “Job ID”.
Logs created after the 22R2 release will have this Job ID appended to the log file name so that the relevant log file for each Build Place or Release Update Studio operation can be easily located for troubleshooting purposes.
Note: This change is applicable for customers who are in any cloud release (21R1, 21R2, 22R1 & 22R2). However, only jobs created after 22R2 release will have the Job ID included in their logs.
Follow the below steps to easily find the relevant log files:
- Perform an operation in either Build Place or Release Update Studio.
- Copy the Job ID from the “Jobs” table.
- Navigate to the “Logs” page of the Build Place or Release Update Studio.
- Use the browser search (ctrl+F) to search the relevant log file.
How to request an Aurena Certificate Renewal¶
In a scenario where any type of build place environment (DEV, QAS, BAS, TOP, DEL) has an alert indicating that the IFS Cloud Web Certificate is about to expire or is expired, similar to the ones shown in the screenshots below, it signifies that the SSL certificate related to the environment is to be expired soon.
There are three types of alerts for this scenario:
-
If the certificate is to be expired in 8-14 days
-
If the certificate is to be expired in 0-7 days
-
If the certificate has already expired
At each of these scenarios, an option will be given to renew the certificate, so that the environment can be accessed without having the risk of facing any security issues.
Note
Please make sure that the environment is in the 'Running' state prior to renew the IFS Cloud Web Certificate.
When the hyperlink shown on the alert is clicked, a confirmation popup will be shown. If you wish to proceed, the 'Confirm' button can be clicked.
Once the certificate update is triggered, the environment will move to the Updating state. During this time, the environment will be inaccessible and user won't be able to perform any environment-related operations.
It'll take approximately 10 minutes - 30 minutes for the certificate to be renewed. Once the operation is completed, the user can continue to proceed with the environment operations without any security vulnerabilities.
Note
Certificate Renewal Feature Availability in Environments
The certificate renewal feature is available for every environment created in 24R2 release and beyond. Furthermore, the feature is also available in the DEV environments created before 24R2 release.
Starting or Stopping Operation Failed¶
If the manual or scheduled starting and stopping operations fail, the environment status will move to "Starting Failed" or "Stopping Failed" respectively. At this point, the option to re-trigger the operation is available to the user and if the operation continues to fail, a support ticket should be raised to get the issue resolved.
Update analyzer error on already existing “UpdaClones” directory¶
When a .upda file downloaded from the LE portal is opened through Update Analyzer, an error message as shown below can be displayed, as cloned files are already existing in previous UPDA clones:
In such an instance the following steps can be followed to resolve the issue:
-
Navigate to the path mentioned on the error message.
-
Delete the UpdaClones folder(s).
-
Re-open the .upda file to run the assessment or analysis.
Unable to download artifacts from Manage Deployments¶
If the artifacts available on the manage deployments page are not available to be downloaded, one of the following options can be followed to resolve the issue:
- Close the browser and load the Lifecycle Experience Portal again.
- Open the Lifecycle Experience Portal on another browser tab.
- Sign out and sign in to the Lifecycle Experience Portal again.
- Clear the browser cache. Eg:- Chrome browser cache clearing option
- If none of the above steps work, contact IFS support teams to get the issue resolved.
Accessing the Database to Troubleshoot¶
If the generation of delivery and topic environments from the Build Place fails, following a successful database deployment, users will have access to the database credentials. In such scenarios, users can access the database using the credentials provided in the Build Place (IFSSYS DB & Application Information sections will be enabled as shown in the screenshots below) to troubleshoot the issues.
While troubleshooting, if the cause of the environment creation failure is identified as a code deployment issue, the fixes can be done by logging into the database using the credentials. Once done, a new environment can be re-ordered to verify the changes.
However, if the generation of delivery and topic environments from the Build Place fails before or during the database deployment, the database credentials will not be accessible.