In this multi-part article with a first and second part. Click here to read the first strategy of OutSystems Mock API Paradigm and here to read the second part.
The many ways of approaching the creation of mock data in a project. Examples and the advantages of each approach: REST/SOAP APIs
REST/SOAP APIs
In this approach to Webservices, the example we are going to follow is REST, we will have a module to emulate the External Service (MockAPI_ES) where we will have to expose the mock method.
- Expose Mock REST API
In REST Integrations we chose the option of exposing a REST API as shown in the image. We create the API and give it a name. The next step is to add the API Mock method.
From here, you can implement a solution similar to that used to expose JSON action.
NOTE: Instead of just having JSON with all the information we want to obtain, it is also possible to create Entities that provide the necessary data.
The big difference with this approach is that we can use OnRequest or OnResponse on the side of the exposed method and OnBeforeRequest or OnAfterResponse when consuming the method, and even put the possible headers, tokens, authorization parameters that are unique to your project, to obtain a mock experience as similar to the final API.
The REST API endpoints are accessible after deploying the application.
https://<server>/MockAPI_ES/rest/MockRESTAPI/GetCustomer_Mock
- Consume the Mock API
The last step is to send the information to Core service layers and make the necessary abstractions.
Mock that allows CRUDs
Here in the mock through the REST API, and also in the JSON in Server Actions, which was covered in the first part, if we want to have mocks that allow us to make CRUDs we have to follow a different approach. To have CRUDs, we have to create the entities necessary for these operations.
Note: We will use the same customer structures, used in the first part, to exemplify here how to proceed.
- Create the mock data in an Excel
- Import New Entities from Excel
- Create and expose the REST API CRUDs
- Create the mock data in an Excel
It is important to note that these mock entities must be created in the External Service module to avoid dependencies that will inevitably be deleted, going to Core Service layers or even End-User layer.
You can create all the necessary entities in one Excel file but with different tabs. i.e:
This way we can replicate the same Customer structure that we have been working with.
Here it is important to note that the name you put in the Excel tabs will be the names given to entities in OutSystems. In the names, it is advisable to always put the suffix Mock to show that these are mock entities. Another point to note is that the CustomerMock table has a CustomerId attribute. This choice, instead of going by the Id of the entity that will be created, is based on the fact that:
- We can control the Id’s in the main table and in the tables that depend on it in a flexibly way
- Allows the emulation of the real Id’s
2. Import New Entities from Excel
This Excel file will be imported into OutSystems using the advanced features. To do this, go to the Data tab in Service Studio and in the Database. Choose the option Import New Entities from Excel …
Choose the file to be imported, this is Customer.xlsx. And you can see that it indicates that 3 entities will be created. Namely CustomerMock, AddressMock and ContactMock.
By clicking on “Import”, automatically the following components are created:
- Entities
- Bootstraps
- Structures
To better understand this process I advise you to see the “Bootstrap an Entity Using an Excel File” and the “How to update a Bootstrap Action to fetch an entity identifier from Excel“. They will be valuable sources of information for those who decide to follow this strategy to mock the data.
To have the data available, just publish and Voilá, the database is prepared.
3. Create and expose the REST API CRUDs
The next step is to create the necessary CRUD actions.
For more in-depth and practical models of how to expose a REST API, using entities, you can see the How to Expose a REST API application or the OutSystems documentation. .
As an example, to expose a method that allows updating, we have to:
a) In the method, set the “HTTP method” property to PUT.
b) Add a Customer as an input parameter. Set to “Body” the “Receive In” property of the parameter.
See this table to help in the perception of which HTTP method you can create for each CRUD.
| HTTP Method | CRUD |
| POST | Create |
| GET | Read |
| PUT | Update/Replace |
| PATCH | Partial Update/Modify |
| DELETE | Delete |
Conclusion
All these approaches that we talked about are valid and can have advantages. These advantages depend on the needs of the project in which we find ourselves. There may be situations where it makes sense to form a hybrid strategy.
If you only need to mock simple CRUD endpoints with basic validations, you may use the JSON in action strategy. If you want a more flexible and customizable solution, choose the mocking API Framework. If the need goes through not only having a customizable solution but also the possibility to update the data the REST / SOAP may be the best option. Of course, hybrid options can also present themselves as a more valid option.
One of the important points to keep in mind is the fact that no structure, action or component of the mock modules should be consumed in the core or end-user modules.
Another point to keep in mind is that, if you have the need to make CRUDS’s and therefore have entities, it becomes even more important to have the external service emulator, separated by concepts, so that when we have the real APIs the transition can be as fluid as possible.
I hope that this article, with very simple examples, has helped in the strategies to follow in the next projects in which you are involved. Let me know your feedback in the comment section, and if you like the article do share.
NOTE: find in the Forge the Mock API Application with the examples.
Visual Codify 