Question
American Express
US
Last activity: 16 Oct 2018 12:03 EDT
Pega OOTB script pega.desktop.createNewWork is invoking a GET request, planning to change to POST
Hi,
We are trying to create new work using OOTB java script function pega.desktop.createNewWork(strClassName, harnessVersion, strFlowName, flowParams,contentID, dynamicContainerID,actionRequestID, skipConflictCheck),
This is by default triggering a 'GET' request to server, we are thinking of changing it to 'POST' by using the below piece of code in the custom function and call OOTB script. Please advise if there could be any side effects (or) any un-seen issues.
function customCreateNewWork(strClassName, harnessVersion, strFlowName, flowParams,contentID, dynamicContainerID,actionRequestID, skipConflictCheck){
pega.web.config.cmd.pegaAction.httpMethod = "POST";
pega.desktop.createNewWork(strClassName, harnessVersion, strFlowName, flowParams,contentID, dynamicContainerID,actionRequestID, skipConflictCheck)
}
We are using Pega 7.1.7, CPM 7.1.3.
**Moderation Team has archived post**
This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.
Accepted Solution
American Express
US
Thank you All,
We modified the way we call, just before CreateNewWork made an extra Asynch POST call to pass the parameters to server. And, left the CreateNewWork as 'GET' which is OOTB. Because forcing OOTB CreateNewWork to POST is affecting other places like the way it generates iframes for tabs.
This is the same way Pega does for CTI call handling, so followed the same design.
Pegasystems Inc.
IN
Hello
Since this has not be tried and tested with POST , i cant comment on the implications of the same.
However, out of curiosity just want to know, what is the business purpose behind changing the type to POST
PEG
US
Generally one would change to a POST if there were a lot of data you were trying to push across -- there is a (I think) 1024 byte limit on the size of the URL for the GET, and the BODY of a POST has no such limit. Be aware that if you pass a pzTransactionID along with the POST, the system will check if this id agrees with the Server's idea of the current database transaction for the given thread -- if it does not match, the POST will be rejected.
American Express
US
Thanks coher, we are sending more data and at times we are seeing special characters in the data which is avoiding saying 'Due to Cross site scripting...'.
To avoid all those, we are thinking of sending in POST.
Can you please elaborate more on that 'pzTransactionID' issue, is there a way we can test it and confirm.
PEG
US
If you are not actually committing any data, then you don't need to provide a pzTransactionID; if the system insists on one, you can leave it blank and that will work. Only if you are going to be performing a commit on the server end do you need to provide the pzTransactionID. The actual mechanics of how you would do this is beyond my expertise -- but hopefully you don't need it?
American Express
US
Hi All,
It seems after implementing fix, we are seeing 'status:Good' message sporadically. Can you please advise if this is because of changing to POST? (or) is there a way to find the cause.
Status: Good
Message: The operation completed successfully, but no content returned.
Operator id:
Requestor id:
PEG
US
For every AJAX request you send across the wire, HTTP protocols expect some kind of answer. Often the request is just to run an activity on the server. In order to prevent the "no content returned" message, you should have the activity add as a last step a "show-property" which just shows the value of the hard-coded string "good".
This will prevent the "no content returned" message.
Accepted Solution
American Express
US
Thank you All,
We modified the way we call, just before CreateNewWork made an extra Asynch POST call to pass the parameters to server. And, left the CreateNewWork as 'GET' which is OOTB. Because forcing OOTB CreateNewWork to POST is affecting other places like the way it generates iframes for tabs.
This is the same way Pega does for CTI call handling, so followed the same design.
Bank of America
US
After making this change, are you able to send more data then 1024byte. Can you please share where and what exactly was changed to achieve this?