I encountered the same error when working with Microsoft.OData.Client v7.9.1. Removing or modifying the If-Match parameter didn’t work for me. For the PATCH request, it seems like the API expects only the modified attributes to be sent. However, the framework was not doing the desired action which resulted in the error. On a quick search into the Microsoft devblogs I found a related post which helped me resolved the issue. [Tutorial & Sample] Client Property Tracking for PATCHThe solution:DataServiceCollection<PartCatalog> parts = new DataServiceCollection<PartCatalog> context.PartCatalogSet.Where(o => o.PartNo == "TESTPART"));parts[0].Description = "test description";DataServiceResponse rs = context.SaveChanges();
Thanks @Kasun Balasooriya for the reply. Switching the authentication method didn’t work for us.One thing we noticed in the application is that there is no traces of new application messages (including failures) for the same queue. I suspect that this issue is occurring before the message reaches the application.
Confirmed with R&D that IAM is new to IFS Cloud due to the security architectural changes. The way to go in Applications 10 is to obtain the client id and client secret from the MWS console.
With further investigation I managed to find the cause of the problem. My client application uses MSAL (Microsoft Authentication Library) to authenticate and acquire token for the user from Azure AD. The library by default uses Azure AD 2.0 endpoints. The tokens returned from 2.0 endpoints are not compatible with IFS Applications 10. Which resulted in the above mentioned error responses.SolutionThe solution was to change the scopes parameter to be compatible with Azure AD 1.0 endpoint. The following documentation details about using MSAL with v1 scope usage.https://docs.microsoft.com/en-us/azure/active-directory/develop/msal-v1-app-scopesBased on this, the scope value “{client_id}/{oauth2Permissions_value}” is used (instead of “openid”).oauth2Permissions_value: this must be obtained from the Azure AD application manifest reference. In my case the value is “user_impersonation”.Application Manifest ReferenceThanks everyone
Have you looked into the following documentation? https://docs.ifs.com/techdocs/Foundation1/010_overview/210_security/030_authentication/oauth2.htm Hi Asitha, Thank you for the reply. I already checked the f1 docs. The flow I am using is Authorization Code Flow and I managed to successfully obtain a token. The failure is resulted when I communicate with IFS APIs using the token. When investigated further on the error description (WWW-Authenticate header) it was bit unclear as the error messages mentions about id_token. As stated in the documentation, when tried with access_token the following response is returned Bearer realm=<client_id>@https://login.microsoftonline.com/<tenant_id>, scope="openid", authorization_uri=https://login.microsoftonline.com/<tenant_id>, error="invalid_token", error_description="573fb18d-3879-400e-88ff-9c8a64ef1135: Signature of the provided id token could not be validated against the public signing keys of the identity provider." When
Thank you for the input @Charith Epitawatta I too have used the IFS MWS console previously to obtain the client id and client secret. I too think it is not an acceptable way to do it nor the best practice. I will try to get confirmation from R&D on this topic and update this thread.
Thanks, DhananjayaI checked that thread before and didn’t find the answer to my problem. I am actually looking for a way to register custom clients in IFS Applications 10. As stated in the other thread, in IFS Cloud there is a dedicated page called “IAM Clients”. But I couldn’t find similar functionality in Apps 10 to do that to obtain client id and client secret.
Hi @Nilushi Silva I am not adding the ‘\r’ character manually - it is added by pressing enter in the client. And, the character you are seeing in the sample response I have provided is due to serialization. As @Albibr pointed out, this seems like a systemic issue that can be seen in many other projects too. In my case, I am planning to build a client using the REST APIs so this kind of issue, if it occurs, can break the client. Hi @avenash, When I check the behaviour in App10 core Aurena client, I was able to add given ‘BaselineRevisionComment’ value without any issues. Are you adding ‘\r’ in client or adding enter in the client and system in the backend adds \r to the field?. Usually, in client we do not have such characters. BR, Nilushi Silva
Thanks, @Nilushi Silva The issue I have is due to a carriage return character present in the value. The field ‘BaselineRevisionComment’ does accept multi-line text and it is a core field.,Byggsats som levereras v:a 2020-21,vi kan faktu The customer is mainly using IEE client and there are no issues. But the problem is encountered when the same project record is retrieved through OData query (REST) or viewed in Aurena client (in customer’s test environment). I tried using the same value in another environment and it didn’t have an issue populating the field in REST response. {..."BaselineRevisionComment": "Ekonomi ville att detta projektet skulle gå i IFS. Byggsats som levereras v:a 2020-21,\r\nvi kan faktu"...}
Already have an account? Login
No account yet? Create an account
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.
