OutSystems Mock API Paradigm (1/3)

The many ways of approaching the creation of mock data in a project. Examples and the advantages of each approach: JSON in Server Action (or Service Actions)

---

The fact that OutSystems is a fast development platform has created a problem in API-driven projects. Blocking teams regarding APIs needs.

Thus, the development team is often blocked due to external API dependencies. This leads to extra work to unblock themselves from those dependencies, through the creation of mock APIs. Mocking is part of the software development lifecycle in almost every organization. And with CI/CD, to continuously develop and test applications you have to handle multiple dependencies.

Some advantages to using API mocks in your development:

• You can begin the user stories even if your external dependencies are unavailable
• You have the flexibility to emulate the API structure you want
• You can repeatedly test the same scenarios
• Frontend developers and backend developers can work in parallel
• The frontend can act as a standalone application during development without any backend API dependencies.
• Easy to demo
• The mock API can easily be replaced with the Real API once it’s ready

The purpose of this article is to help reduce the negative impact that the uncontrolled creation of mock data can have on projects and applications that are being developed, through 3 different approaches to building mock APIs in OutSystems.

This article will show how you can begin frontend development by mocking the backend through these 3 simple approaches:

• JSON in Server Action (or Service Actions)
• API mocking frameworks and tools
• REST/SOAP APIs

In this first part of the article, the JSON in Server Actions strategy will be addressed.

For any of the approaches, the first step is to disclose the needs, i.e. the structures that are necessary. For us to have a practical case here, let’s imagine that we need to have the following customer data:

JSON in Server Actions

The first approach we are going to explore is JSON in Server Action. The approach of creating mock data through server actions can be the simplest and often it must be the approach used. As is the case of wanting to retrieve information without having to update the data permanently. With this approach, all parameterizations that could be made through Webservices, such as OnBeforeRequest or OnAfterResponse, are absent.

NOTE: This JSON in Server Action must be created as an external Source of information (ES), below the Integration Service (IS) layer. Thus, none of the actions or structures created in this layer should be consumed by any module other than the Integration Service (IS).

1. JSON Structure Creation

To easily create the JSON structure of this case study, we can use the objgen tool which in a simple way can generate a first JSON structure version.

After proceeding to the complete definition, we can arrive at the following structure (here already filled with data):

[
  {
    "firstName": "John",
    "lastName": "Smith",
    "age": 25,
    "address": {
      "streetAddress": "21 2nd Street",
      "city": "New York",
      "state": "NY",
      "postalCode": "10021"
    },
    "contact": [
      {
        "type": "home",
        "phoneNumber": "212 555-1234",
        "email": "john.smith.home@mail.com"
      },
      {
        "type": "fax",
        "phoneNumber": "646 555-4567",
        "email": null
      }
    ]
  },
  {
    "firstName": "Jane",
    "lastName": "Smith",
    "age": 22,
    "address": {
      "streetAddress": "21 2nd Street",
      "city": "New York",
      "state": "NY",
      "postalCode": "10021"
    },
    "contact": [
      {
        "type": "home",
        "phoneNumber": "212 555-1234",
        "email": "jane.smith.home@mail.com"
      },
      {
        "type": "fax",
        "phoneNumber": "646 555-4567",
        "email": null
      }
    ]
  }
]

This structure can be validated and formatted/indented using tools such as JSON formatter. It should be noted that this JSON structure if the team that will develop the APIs has not yet finished defining the data model, can be delivered as a suggestion so that what they produce is similar to what is being created in the mock.

2. Add JSON structure in Service Studio

In Service Studio you can create the structure from JSON in a very simple way.

a. Add structure from JSON…

b. Name the structure and insert the JSON to generate the structure, and click on the “Add structure” button.

c. After the creation of the structures is necessary to put them as public:

d. The next step is to create the server action that will be made available to emulate the API.

In this step of creating the server action, it makes sense that the name of all mock actions has the _Mock extension (i.e. GetCustomer_Mock).

e. Mock action logic

To obtain the JSON data in the mock action we have to use the JSON Deserialize component where the Data type is of the type Customer, created earlier, and the JSON String used is the same as the one used to create the structure.

IMPORTANT: here it is important to note that in the JSON that will be placed in the JSON String of the deserializer, all quotation marks (“) should be replaced by single quotes (‘).

This action, GetCustomer_Mock can now be consumed in the IS module to be able to emulate what the API would be doing and in this way, we keep the Integration Service module isolated in terms of a set of mock components.

3. Consuming JSON in Server Action

The last step is to use JSON in Server Action in the Integration Service module.

It is important not to consume MockAPI_ES structures in non-Foundation modules. Therefore one must make an abstraction of these attributes.

NOTE: find in the Forge the Mock API Application with the examples.