Lifecycle Experience Portal Troubleshooting Issues¶
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.
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)
Logs related to "Buildplace" are here.
Release Studio Logs¶
Logs related to "Release Studio" are here.
- Error logs are shown in red color text . The download icon  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.