Implementing Error Handling for REST Service: Pega How-to Guide

In our earlier codes, we had simply returned “200” (success) for all situation. However, in an actual project implementation, this approach is not acceptable.

 

At the very least, you should always provide at least the “200” (for success) and “500” (for failure).

 

Let’s go back to the earlier REST service. Since the GET method example that we did earlier did not take in any parameters and basically just return a hard-coded message, it would be more difficult to use that as an example to demonstrate the different error code.

 

Therefore, we shall modify the POST method such that it could conditionally return either “200” or “500”, based upon some inputs of ours.

 

Changes to the Service REST

Method Tab

The first change is to make the response status code dependent on a variable that we set.

 

Since “Param.StatusCode” was used in Pega’s REST service, let’s use that parameter too.

 

In the Service REST: “DBTestService”, update the “Status code” as follows:

 

Figure 83: Updating REST Service Status Code to Use Param.StatusCode

Service Activity

Since we had modified the status code to be based on “Param.StatusCode”, we would need to modify the Service Activity to set that as either “200” or “500” accordingly.

 

Instead of just highlighting the changes here, I felt it is better to list everything here again, highlighting the changes required. This would allow you to have a fuller picture of the changes without the need to scroll back to look at the whole context.

 

Step 1: (No changes)

 

Figure 84: Implemented Error Handling - Step 1 of POST Activity

Step 2: (Added the StatusCode 500 and “Jump” Condition)

 

Figure 85: Implemented Error Handling - Step 2 of POST Activity

Remember that the Step 2 was meant for error checking? So, if this step is reached, we shall set the “StatusCode” of “500” here.

 

As for the details of the “Jump”, it is as follows:

 

Figure 86: Step 2 of POST Activity – Settings for the Jump Conditions

 

⚠	Warning: You would not be able to define the “Jump” because the “RET” label is not defined yet! It shall be defined in Step 4! So please take note of this and come back to edit it after you have implemented Step 4!

 

💡

Note: In activity step, the “When” is being testing before the step, so as to decide if you are going to run that step. The “Jump” will only be tested if that step had been run!  Since our logic is that if this step is run (i.e. there is error), we would want to skip the Step 3 (which is setting the “WelcomeMsg”). Therefore, the “Jump” condition was set as “Always”, which means that if this step is run, I would always want to skip the Step 3 by jumping to the step marked with the “RET” label.

 

💡	Note: The “Jump” setting is available at the right side of every activity step. This allows you to make a decision on what to do next based on the outcome of the given step.

 

💡	Note: The “Always” When rule is an OOTB When rule, which always evaluated to true. The opposite of it is “Never”, which never evaluate to true! [Quite a nice naming convention!]

 

Step 3: (Added the StatusCode of 200)

 

Figure 87: Implemented Error Handling - Step 3 of POST Activity

Since Step 3 is our “OK” step, we shall set the “StatusCode” of “200” here.

 

Step 4: (Added the “RET” label)

 

Figure 88: Implemented Error Handling - Step 4 of POST Activity

 

Testing the REST POST Method Again

Now we are ready to test the method! To simplify the testing, let’s use Pega OOTB testing tool that we used earlier.

 

Go back to the “Service REST: DBTestService”, and select the “Actions -> Run”:

 

Figure 89: Launching the OOTB Test REST Service Tool

 

In the pop-up dialog, select the HTTP Method as “POST”, leaving the Message Buffer as empty and then click on the “Execute” button.

 

Figure 90: Execute the REST POST With Empty Input for Error Testing

This would produce an error because this service expects a properly formatted JSON input. The following is the output, with “StatusCode” of “500”:

 

Figure 91: Sample Error Output With StatusCode of 500

Now let’s test the successful scenario by entering this earlier input again:

{   "name": "Debunkum Beaver" }

 

The following is the dialog:

 

Figure 92: Execute the REST POST With Earlier Valid Input

After executing it, you will see the following:

 

Figure 93: Sample Success Output With StatusCode of 200

Well, you have successfully implemented error handling for your REST service!

 

💡	Note: The above demonstrated how to implement error handling and setting the status code, however, the actual status code would depend on your specific scenario.

 [Back to Online Version content page]

[Check the How-to Series availability here]