Question
Pegasystems Inc.
GB
Last activity: 8 Nov 2019 17:10 EST
LSA 7.3 - Exercise: Creating the REST integration interface
In the section Configure the REST Connector, the instructions specify for the PUT request to enter actionID as a query string parameter. I followed these instructions and I would get a server 500 error when running the connector through the ConfirmRooms activity. If I specify it as a Headers entry, then it will work correctly and return a 204 success.
I verified this by checking the solution .zip files on another VM and I could see the actionID was configured as a Header and not a QueryString parameter.
I do see that on the PegaAPI swagger, the actionID is listed as a Query String parameter, so this does confuse me...
-
Like (0)
-
Share this page Facebook Twitter LinkedIn Email Copying... Copied!
Pegasystems Inc.
US
You are correct that the Pega API landing page, for cases PUT /cases/{ID}, says that the actionID parameter's type = "query'.
Apparently the landing page is in error (and not the LSA course :- )
Saltech Consulting
GB
Filename: lead-system-architect-exercise-guide.pdf
Title: Lead System Architect 7.3.1 Exercise Guide
On page 45, in section Configure the REST Connector, the following can be found:
So the actionID parameter should be in the Headers instead of the Query string parameters. Could you, please, confirm this?
Pegasystems Inc.
US
The HTTP 500 could have been caused by Tomcat not being in a ready state.
Action ID does belong in the header. The study guide is wrong.
TapRoot Solutions LLC
US
HI Lee, Can you please share the above screen shot by expanding the GET method if possible to see the response headers.
Pegasystems Inc.
US
In the REST connector's GET response, the Etag header would be mapped to param.eTag which is subsequently used in the PUT request as the If-Match header.
Information about ETag can be found in Wikipedia: https://en.wikipedia.org/wiki/HTTP_ETag
As explained ETag can be used an optimistic concurrency control technique: https://en.wikipedia.org/wiki/Optimistic_concurrency_control
-
Siddhant Suryakant Jivane
TapRoot Solutions LLC
US
I Agree with info you provided Lee, my concern was how would you do that mapping is a question. I did do my mapping as the attached screen shots and it is not working.
sharath
Pegasystems Inc.
US
What does "not working" mean? Are you getting HTTP 500 or something else?
You can enable extra logging, for example: Rule_Obj_Activity.Invoke.Rule_Connect_REST.Action
The case/{ID} api REST Service can be traced as well.
The problem is either on the server or the client (your REST connector).
TapRoot Solutions LLC
US
Lee, I am able to get the response. However, the response header eTag is not seen in the Pega response. I was able to trace and the tracer doesn't show the header values.
TapRoot Solutions LLC
US
Hi Lee,
How is the GET method response header captures in this scenario? I mean etag on the response header. Can you share the screen shot of it.
Thanks,
Sharath
Pegasystems Inc.
US
All done in the REST connector which shares the same Parameter Page as the Activity that invokes the connector.
TapRoot Solutions LLC
US
Thanks for your quick response. The Wizard didnt map my response headers
Pegasystems Inc.
US
If mapping a received header value to the Clipboard, you have to name a property or parameter.
The latter makes more sense since the received value is temporary.
Perhaps a bug in 7.3.1's REST Connector Wizard to leave the target blank.
The Wizard could, perhaps, attempt to invent a parameter name based on the header name.
TapRoot Solutions LLC
US
We are in 8.2.2 and the response headers were not created during the wizard. Not sure, if it has any bug.
Thanks,
Sharath
TapRoot Solutions LLC
US
I don't see any Comment, Did I miss anything?