Question
Ameriprise Financial Inc
US
Last activity: 9 Aug 2021 10:44 EDT
Not able to get etag header in response while calling GET request using c# or other rest client
When I am calling the GET method of the below API in Pega using run command of API rule then it is returning etag in the response header which I can use to call next API call where I need to update that resource.
https://<host:port>/prweb/api/v1/cases/{ID}
However, when I am calling same API using any other rest client C#, Postman, YARC I am not receiving etag in response header.
Is there anything extra I need to pass in my request header to receive etag in response header.
Maantic Inc.
IN
@ManishM5893 I am able to get the eTag successfully. You just need to provide a valid pzInsKey in the url and hit the API with proper authorization token. I have oAuth2.0 configured hence I had to generate the token prior to this using token API.
Ameriprise Financial Inc
US
@Tanay Kumar Bal , Thanks Tanay for the response!
I am supplying the right pzInsKey and getting the success 200 response along with the case details. However, its just that eTAG is missing in response header.
Could you please send me the request headers too so that I can verify if anything is missing in my request header which is the reason of eTAG absence in response header. And which API client you have used to hit the service ?
Currently my request header contain Authorization and Accept headers.
Maantic Inc.
IN
Here you go. However, I think, there must be some other problem though. Can you verify if the property pxSaveDateTime has been generated for your case that you are trying to get using the cases/{id} API?
Ameriprise Financial Inc
US
@Tanay Kumar Bal Yes Tanay, I am getting this property in the response body "pxSaveDateTime":"2021-08-03T18:04:42.076Z" . As of now, I have used this property and converted it to ("yyyyMMddTHHmmss.fff") format to sent it as eTag value and I am able to update my case but it doesn't seems to be a robust solution as if algorithm changes from Pega end to generate eTag then it will fail. Is there anything else you foresee could be wrong that eTag not being present in response header.
Maantic Inc.
IN
Can you trace the service and note activity pzGetCaseDetails step #2?
Also - Are you trying to get the eTag to ultimately update the case? If yes, then actually you can get the real eTag by calling the update case API itself with a dummy invocation first - then get the actual eTag in the response header and then again call the update case with the correct If-Match value. Though this doesn't look good but the OOTB behavior is such. I have raised this as a change request as well in form of an idea since it seemed to me as a vulnerable behaviour.
https://collaborate.pega.com/idea/pega-api-update-case-etag-and-if-match-issue-security-concern
