PeopleTools REST Based Web Services Removing Response

Update: According to Doc ID 1514606.1 this may be fixed in 8.54.

I have been struggling with REST based web services in PeopleSoft. They are not flexible and they are poorly documented. Additionally, the JSON support is absolutely horrendous and full of bugs. This will be one of several posts regarding issues with PeopleTools REST based web services. In short, I can’t really recommend that they are ready to be used in production.

I have been working with the REST API for OKTA which is an Identity Management Provider (IDP) hosted in the cloud. They have a very simple and robust REST API that is extremely well documented

These OKTA APIs allow you to create users in the IDP and do operations like add a user to a group, reset passwords, de-activate users, etc. In my case, I was trying to call one of the end points from PeopleSoft to create a user. It should be relatively simple.

Here is a straight copy and paste from their docs. It is a simple JSON post to an endpoint can can be done with curl like the following.

curl -v -H "Authorization: SSWS yourtoken" \
-H "Accept: application/json" \
-H "Content-Type: application/json" \
-X POST "https://your-domain.okta.com/api/v1/users?activate=false" \
-d \
'{
   "profile": {
      "firstName": "Isaac",
      "lastName": "Brock",
      "email": "isaac@example.org",
      "login": "isaac@example.org",
      "mobilePhone": "555-415-1337"
   },
   "credentials": {
      "recovery_question": {
      "question": "Who\'s a major player in the cowboy scene?",
      "answer": "Cowboy Dan"
      }
   }
}'

There are two scenarios that can happen from the API.

• The service returns HTTP 200 SUCCESS and a JSON object is returned representing the new user object. This response may look like the following (copy/paste from OKTA documentation)

    {
      "id": "00u1ero7vZFVEIYLWPBN",
      "status": "STAGED",
      "created": "2013-07-02T21:36:25 344Z",
       "activated": null,
       "statusChanged": null,
       "lastLogin": null,
       "lastUpdated": "2013-07-02T21:36:25 344Z",
       "passwordChanged": null,
       "profile": {
          "firstName": "Isaac",
          "lastName": "Brock",
          "email": "isaac@example org",
          "login": "isaac@example org",
          "mobilePhone": "555-415-1337"
       },
       "credentials": {
          "recovery_question": {
            "question": "Who's a major player in the cowboy scene?"
          },
          "provider": {
            "type": "OKTA",
            "name": "OKTA"
          }
       },
       "_links": {
          "activate": {
            "href": "https://your-domain okta com/api/v1/users/00u1ero7vZFVEIYLWPBN/lifecycle/activate"
          }
       }
    }

• The service returns HTTP 400 BAD REQUEST and a JSON document is returned that has some error information. An error response may look like the following. In this case, the API tells you that you are tried to create a new user but a user already exists with that LOGIN.

   {
   "errorCode": "E0000001",
   "errorSummary": "Api validation failed: login",
   "errorLink": "E0000001",
   "errorId": "oaeMSG1q6OPR8KJGn6-fDbmog",
      "errorCauses": [
         {
         "errorSummary": "login: An object with this field already exists in the current organization"
         }
      ]
   }

When I started to call this web service from PeopleSoft to test the error condition, I was having an issue getting the JSON for the error condition back in the PeopleCode so I could log it so some action could be taken later.

I was getting the HTTP 400 but the JSON for the error message was not there. Using the method GetContentString() on the response message just gave me this.

Http Response Status 400 - Bad Request The request cannot be fulfilled due to bad syntax.

When I dug deeper and looked at the msgLog.html on the integration broker, I saw that the error JSON returned from the web service was not even showing there at all. I could see the full request going outbound but the response coming back looked like this in msgLog.html.

Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-Disposition: inline
Content-ID: ContentSection0

Http Response Status 400 - Bad Request The request cannot be fulfilled due to bad syntax.

I was scratching my head. So I fired up PostMan and tested submitting the same request. Postman was showing the API returned a response of Content-Type application/json with the JSON error message as expected.

So the API returned JSON and the PeopleSoft connector did not pass it along and decided to return to the invoking PeopleCode that the response was Content-Type: text/plain; charset=UTF-8 and inserted in the HTTP Response code text in place of what the API returned.

Additionally, the service operation call was in an “error” status in the integration monitor. That seems to be the source of the issue. The connector sees something other than HTTP 200 and thinks it is an error and it just shuts the interaction down. However, what should be happening is that the error should be returned because the calling code could read the response and take some action to correct the situation and move on.

This is a serious limitation/bug. If you can’t get what the web service returned then this is almost useless.

I hope there is some setting or workaround for that I have not discovered yet. If you know of one please contact me and I will update this KB article.

Additional Reading

• see the article Using Apache HttpClient from PeopleCode on how to work around the limitations.