Testing the REST-Based BlackLine Web Services
Overview
This document will outline how to test the BlackLine REST-Based Services to verify that they are working
correctly. Please note that the testing of the services will assume that basic vanilla configuration has been done
within the financial accounting (FA) area. If one or more of the services do not work correctly, minor tweaks may
need to be made in the testing payload to ensure veracity.
Section 1 – Prerequisites
This section will outline will outline the components that need to be present in order to test the services correctly,
which are:
1. Web browser (this document will use Chrome for its examples).
2. REST-based testing plug in that can handle REST-based commands (this document will use POSTMAN for
its examples).
3. A service and/or dialog-based user that has the ability to connect to the SAP system through the SAPGUI.
4. A direct connection from the user’s workstation to the SAP logon.
5. Access in SAP that allows for testing of the BlackLine based components (please see the BlackLine RESTbased setup guide for details on authorization).
Section 2 – Web Browser Setup
As explained above, the web browser that this document uses is Chrome, which can be retrieved and installed as
follows:
1. Navigate to either the URL: https://www.chrome.com or the URL: https://www.google.com/chrome
2. Go up to the top of the web page, and select the option to Download and either For Personal Computers if
using a workstation, or for Mobile if using a mobile device (this document will use examples for a
workstation).
3. On the next web page, select the button to being downloading Chrome.
4. On the popup that appears, choose the appropriate checkboxes to ensure that the installation process can
proceed.
Section 3 – REST-Based Testing Plug-In
As explained above, the REST-based plug-in that this document uses is Postman, which can be retrieved and
installed as follows:
1. Navigate to the URL: https://chrome.google.com/webstore to get to the home page for all of the Google
applications.
2. In the search window, type in postman rest client to search for the PostMan REST-based client application
plug-in.
3. When the list of applications appears, the Postman REST-Based client will have the following icon:
4. Click on the Add to Chrome button to add it the Chrome web browser.
5. Once it is added, the application should appear in the list of applications that have been installed for Chrome.
If the list does not appear, the list of applications installed for Chrome can be brought up using the URL:
chrome://apps from where the Postman REST client should be visible.
Section 4 – Login to SAP
As mentioned above, a service or dialog-based user needs to exist that can be used to log in to the SAP system
from Postman (please note that if using a dialog-based user, make sure that the password has already been set
inside of SAPGUI). Service based users do not have the same restriction as they are expected to be used by a
service and hence never require a password change.
Section 5 – Validation Service Active Testing
The validation service can be tested as follows:
1. In Postman, use the Normal authorization mode, and select Raw text data to allow for a form-based payload
to be added to the service call.
2. The simplest call to verify that the service is working without having to tweak parameters is the following:
<protocol>://<server>:<port>/blweb/rest/fi/validate
Please specify values for the dynamic placeholders. The <protocol> is usually HTTP, however, depending on
how access to the SAP system is setup, HTTPS can be used as well. Either should be able to access the SAP
system. The <server> and <port> specifiers need to be the fully qualified name of server and TCP port,
respectively.
3. Once the URL is entered (no payload) from Postman, and the Send button is clicked, a popup will appear
asking for the user’s credentials. In this case, a simple user/password will suffice.
4. After the username/password have been entered, the following response should be received if the web
service is indeed working (for formatting purposes select Pretty and JSON for the format.
5. While this does provide an error, it is showing that the HTTP status code is 200, and the value “rcode” is
indicating that an application-level error occurred (anything other than a value of 0000 indicates an error).
6. Verifying that the logging worked correctly can be done by logging into SAP into the default client.
7. Goto transaction SE16 and enter in table name /BLWEB/RSCL.
8. There should be 1 entry in the table. Due to the fact that the call was a “failure”, the log will look as follows:
Please note that not all of the parameters were passed to the log due to the failed call. Additionally, the field
LUSER should have the username of the SAP user that called the service.
9. If the service was not up and active, the following response should occur:
10. In this case, the HTTP status code is 403 “Forbidden”. If this occurs, please activate the service.
Section 6 – Document Simulate Service Active Testing
The FI document simulation service can be tested by using the same steps as outlined in section 5, however, for
the web service URL, use the following:
<protocol>://<server>:<port>/blweb/rest/fi/document/check
Please use the same values as specified within Section 5. If the call is successful, the HTTP status code should
be 200, while if the service is not active, then the HTTP status code will be 403.
Section 7 – Document Post Service Active Testing
The FI document simulation service can be tested by using the same steps as outlined in section 5, however, for
the web service URL, use the following:
<protocol>://<server>:<port>/blweb/rest/fi/document/post
Please use the same values as specified within Section 5. If the call is successful, the HTTP status code should
be 200, while if the service is not active, then the HTTP status code will be 403.