Implementing HelloWorld Service REST POST Method: Pega How-to Guide

Now, let’s turn our attention to the POST method. Actually, the POST method structure is very similar to that of the GET method.

 The 3 things that need to be implemented are still the same:

• Activity name
• Request
• Response

 However, POST method allows you to send a JSON formatted string as input, while the GET method doesn’t!

Creating the Service Activity

Similarly, let’s create the activity for the POST method, giving it the name of “DoDBTestPOST”, as shown below:

 

Figure 43: Specifying POST Method Service Activity

 

Figure 44: Service Activity for POST Method

As before, let’s fill in the Request and Response first.

Specifying the Request and Response

Since the POST accept a JSON message format for both Request and Response, let’s specify them as such.

Figure 45: REST Request “Message Data” for POST Method

 

Figure 46: REST Response “Message Data” for POST Method

As you can see, it is relatively simple isn’t it? Well, this is because I had simplified everything! I had moved away from the laborious class structure definition and different type of message data mapping and streamlined it into a single type, using “Param.JSON”. This approach could handle all possible scenario.

Implementing the Service Activity for POST Method

 Similar to the GET method earlier, we now have Pega passing us the JSON input via the “Param.JSON”, as well as accepting the return through the same “Param.JSON”.

 So, let’s extend the earlier HelloWorld example. In this case, we will pass in our name for Pega to customize the “HelloWorld” message.

 The following is the input JSON that we are supplying to the REST POST method:

{   "name": "Debunkum Beaver" }

Figure 47: Sample JSON Input for REST POST Method

Basically, there is only 1 parameter, which is the “name”, that we would be passing to Pega. Pega would then provide us with the personalised welcome message.

 This time round, let’s do it slightly differently. Remember that earlier for the GET method, in the “Pages & Classes” tab, we have defined the “MyResponse” as a page of type “$ANY”?

 By doing that we had actually declared a clipboard page, named “MyResponse”.

 If we were to use the same approach, we would need to define another “MyRequest” similar to the “MyResponse”.

 Well, there is nothing wrong with that, but the clipboard page might start to get untidy.

💡	Note: You can simply think of “Clipboard page” as some “Global Variables”. To be more precise, it has only thread scope.

 Therefore, for this POST method, let’s declare the “MyRequest” and “MyResponse” as a ‘member variable’ of the “DB-DBRest-Int” class instead. At the same time, let’s continue to specify its type to be “$ANY”.

Create MyRequest & MyResponse Page Properties

The following are the property settings for the “MyRequest” and “MyResponse” for the “DB-DBRest-Int” class:

 

Figure 48: Defining MyRequest as a Page Property of the DBRest Integration Class

 

Figure 49: Defining MyResponse as a Page Property of the DBRest Integration Class

With the above declarations, basically, the DBRest integration class now has 2 properties: “MyRequest” and “MyResponse”, both are of Page type.

 For the above 2 properties, “MyRequest” and “MyResponse”, we shall use that to store the request message passed to the class, and the response message that is produced by this integration class respectively.

 Now let’s update the “DoDBTestPOST” Service activity.

Pages & Classes Tab

The following is the Pages & Classes tab of the “DoDBTestPOST” service activity:

 

Figure 50: Pages & Classes Tab of DoDBTestPOST Service Activity

Since we had decided to use properties within the integration class itself, this tab is basically blank.

Steps Tab

The following are the steps for this service activity.

Step 1: Init values and convert the Param.JSON into MyRequest Page

Figure 51: Step 1 of REST POST - Init values and convert the Param.JSON

In this step, we initialized both the “.MyRequest” and “.MyResponse”, as well as making a call to the “pxConvertStringToPage” function to convert the “Param.JSON” into the “.MyRequest” page so that we can start manipulating it.

💡	Note: Recall in the “Service REST: DBTestService”, I had told Pega to pass the Request message data as “Param.JSON”! That is why I am getting that “Param.JSON” and transforming it to the “.MyRequest” property of the Int class object, using the “pxConvertStringToPage” function.

 

Step 2: Handle error when the input is invalid

According to the specification of the function: “pxConvertStringToPage”, if there is any problem, it will return false and set the error reason in “Param.errorMessage”.

Therefore, in this step, we will create a “When” condition, that tests for “Param.MyStatus==false” as shown below:

Figure 52: Step 2 of REST POST – When Rule

The step itself is as follows:

 

Figure 53: Step 2 of REST POST – Set Error Status and Message

Of course, this is not the best error handling, but just a quick demonstration to illustrate the idea.

💡	Note: Since error in the request message data would typically render all processing invalid, it is more appropriate to create some error code and return as a “500” error instead of the current hardcoded value of “200”. In the Master Beaver Version, we will investigate that!

 

Step 3: Set the welcome message

Figure 54: Step 3 of REST POST - Set Welcome Message

In this step, we set the welcome message to be returned, as well as echoing the name that was passed in earlier.

Step 4: Convert Pega's page structure to JSON

In this last step, we convert the response message that we want to return, back into JSON format by using the function: “pxConvertPageToString”.

Figure 55: Step 4 of REST POST - Convert Pega's Page Structure to JSON

Well, the implementation is completed, let’s test it!

[Back to Online Version content page]

[Check the How-to Series availability here]