Implementing HelloWorld Service REST GET Method: Pega How-to Guide
In general, GET method is the simplest to implement and test. If you are not passing in any header info, you could simply use a Chrome browser to do that.
Click on the “Methods” tab of the Service REST rule. You will be presented with 4 methods to choose from (GET/POST/PUT/DELETE).
Expand the “GET” method, the configuration for “GET” method will be displayed.
It may look intimidating, but actually, there are only 3 things that you need to be concerned with:
- Activity name
- Request
- Response
Note: In Pega V8.x, you have another PATCH method.
The “activity name” specifies the activity that you want to run when this Service REST’s “GET” method is invoked.
The “Request” allows you to define the input that you pass in, while the “Response” specifies the output from the service.
Creating the Service Activity
Let’s specify the activity name as “DoDBTestGET” and click on the icon on the right to create it.
In the opened form that is shown below, take the default and click on the “Create and open” button.
The following shows the created activity. Just click “Save”. We will keep the activity empty for now.
Specifying the Request and Response
For a start, let’s not take in any parameters, so we shall keep the “Request” form empty, as follows:
For the “Response” form, there are basically 3 things that we need to set:
- Content Type
- Status Code
- Actual Response
“Content Type” tells the caller, such as the browser, what type of information we are passing back. In our case, we will be returning the data as “JSON”.
“Status Code” specifies the outcome of the call. For example, if there is a server error, we will return “500”, if it is a success, we will return “200”.
Note: Do you find the “Status Code” of “500” and “200” familiar? Yes, those are the standard HTTP error code!
As for the “Actual Response”, we can return some headers as well as the actual message data.
For a start, we will not return any headers, but focus only on the message data.
There are many ways to specify how you are going to return the data. You could return the data as a Clipboard, Constant, JSON, XML Stream, HTML Stream, etc.
However, we will use a method that would work for all cases and one that is very easy to implement and manage.
In this case, let’s configure the “Response” tab as follows:
From the above, we have configured the “Content Type” to be “application/json”, “Status code” as “200”.
Status code of “200” basically said that it is always a success, which we should not be doing blindly. However, since this is a quick illustration we shall proceed as such first.
For the message data, we are going to provide a properly formatted JSON string to be returned to the caller directly. This is generally the easiest and most manageable approach.
Note: Variables in Pega is denoted by “Param”. So if you are declaring a variable called “JSON”, it is represented as “Param.JSON”.
In this case, our service activity will prepare this “Param.JSON” for us.
Note: Think of “Param” as some forms of global parameters, to be more precise, if you had done Servlet, etc, before, it is similar to those “Request variables”, which has a ‘page scope’, something that could actually be lost if you do not propagate it down the chains of calls.
In my other upcoming books, I will explain to you how to avoid the param altogether and use a different approach, which give you more control and traceability. It is something that is a bit ‘naughty’, but in a real-world implementation, it is more practical and reliable.
Implementing the Service Activity for GET Method
So now, the job of the service activity is very simple. All we need to do is to make sure that it returns the variable “Param.JSON”, which is a JSON formatted string.
We could try to manually formulate the JSON string, but that would be too tedious! An easier way is to leverage on the Pega structure, and then convert it automatically to a JSON string.
Back to the “DoDBTestGET” that we created earlier, perform the following.
Pages & Classes Tab
In the “Pages & Classes” tab, enter the “Page name” as “MyResponse” and the “Class” as “$ANY”, as shown below:
Note: The class type of “$ANY” basically tells Pega not to be bothered to validate the structure and allow me to do it any way I want it. Generally, it is not recommended, but for a demo and quick test, it is much easier for you to take this approach than to be bothered with all the classes and properties creation!
In later chapters, I will explain why in some situations, it does not make any practical sense to define all the properties right up front!
Note: You may have noticed that the class type of “$ANY” is used extensively by Pega, of course if you understand the purpose and implementation, like I do, you are free to use it! However, make sure you are able to justify the advantages of using it versus not! BTW, nobody will ask you in CLSA exams, you are not supposed to be talking about this in the first place!
Steps Tab
In the “Steps” tab, enter the following:
Basically, there are only 2 steps:
1) Set the “Hello World from Pega!!!” string
MyResponse.WelcomeMsg → “Hello World from Pega!!!”
2) Convert that string into JSON
Param.JSON → @pxConvertPageToString(tools, MyResponse, ”json”)
Note: The function “pxConvertPageToString” is OOTB. There is also a corresponding function “pxConvertStringToPage”! So, with these 2 functions, we are free to convert from JSON to Pega structure for manipulation and from Pega structure to JSON for returning!
Note: Generally, it is a good practice to remove all unused pages, in this case the “MyResponse” page. This is usually done at the last step of the activity, using the “Page-Remove” method.