5. AutoStub Features

The AutoStub homepage for a user/admin is displayed as shown below.

Fig. 5.1 User/Admin Home page

Click Upload Specs to access the Upload Specs page. This is the core AutoStub page where you can create mocks. Here you can upload swagger/wsdl files and generate mock data. Swagger files can have JSON or YAML extension.

Fig. 5.2 Upload Specs

Once the swagger/wsdl services are added, they will be displayed on the service panel on the left of the page. The service panel displays a list of all services/projects (both swagger and wsdl) that have been uploaded in the application.

Note

Upload Specs page will not be visible to Super Admin as they cannot generate mock data.

5.1. File Upload

AutoStub allows users to upload the files in following formats in order to generate the data:

1. Swagger/Zip Files
2. WSDL/Zip Files

Note

• AutoStub supports multiple reference json/yaml files with a master swagger file upload. Compress the files to a zip file to perform multi reference upload.
• AutoStub supports multiple reference xsd files with a master wsdl file upload. Compress the files to a zip file to perform multi reference upload.

5.1.1. Swagger Service File Upload

5.1.1.1. Upload a Single Swagger Service File

1. From the File Type drop-down, select option Swagger/zip file.
2. Click Choose File to upload a Swagger 2.0/ 3.0 specification file stored locally on your computer.

Fig. 5.3 Single Swagger File Upload

3. Click Submit. The added swagger service will be displayed on the service panel on the left.

Fig. 5.4 Single Swagger File

About Swagger specification files:

1. AutoStub supports both Swagger 2.0 and Swagger 3.0 specification files.
2. User can define the minimum length and maximum length parameters in the Swagger 2.0/3.0 specification file. If the minimum and maximum length is defined for parameters, the array of object with min and max length of data will be generated.
3. If a swagger 2.0/3.0 specification file has parameter formats like float, date, datetime, timestamp and int64, it will be supported in the request/response of the particular schema having those formats. Mock data will be generated based on the parameter format in the specification file.
4. If a swagger 2.0/3.0 specification file has parameter patterns like A^&*a, those will be supported in the request/response of the particular schema having those patterns. If patterns are defined for particular properties Faker functions cannot be attached. Note that the pattern keyword in the specs allows user to define a regular expression template for the string value. Only the values that match this template will be accepted. Regular expressions are case-sensitive, that is, [a-z] and [A-Z] are different expressions. Example: ‘^d{3}-d{2}-d{4}$’

5.1.1.2. Upload a Zip File

Upload a compressed file that contains .json file or .yaml file and its dependencies. When a user uploads a zip file, a drop-down will appear that will display the swagger master file with the extension .json or .yaml.

To demonstrate the swagger zip file upload, we have considered a zip file named external_ref.zip which contains the master swagger.json.

1. From the File Type drop-down, select option Swagger/zip file.
2. Click Choose File to upload a zip file.
3. On uploading the zip file, a drop-down appears. Select the master file swagger.json.

Fig. 5.5 Zip Swagger File Upload

Note

You can upload multiple reference swagger files.

4. Click Submit. The added service will be displayed on the service panel on the left.

Fig. 5.6 Zip Swagger Service

5. Click on a service/project name.

6. Click the drop-down to display the list of resources under that service. You can further drop-down to display the http methods such as POST, GET etc. In the below image, swagger.json is the service name, /pets is the resource name and get and post are the http methods.

Fig. 5.7 Resource Name and Methods

7. Click the delete icon corresponding to the service name, to delete the service.
8. On successful upload of swagger files, click the service name to display request and response parameters on the Config Data page.

Fig. 5.8 Request and Response Parameters for Swagger

9. To view all the request and response parameters, scroll to the end of the Config Data page. The request and response parameters consists of Variable Name, Variable Type, Source and Function Name.

The table below describes each field in detail.

Table 5.1 Request and Response

Request/Response fields	Description
Variable Name	Refers to the attribute name contained in the uploaded service file
Variable Type	Type of the variable
Source	Refers to the source of generating the mock data
Function Name	Refers to the function associated with the attribute name.

On the Config Data page, for each method, the response code that will be returned by the server is also displayed. The user has to define a default status code (wherever applicable) before data generation.

Fig. 5.9 Sample Default Status Code Before Data Generation

Default status code allows the user to define a common structure for a status code. Status code can either be a success code or an error code. Once the default status code is defined, irrespective of any action performed by the user, the system will throw this default status code after data generation. The default status code (wherever applicable) will be displayed along with other response codes.

Fig. 5.10 Sample Default Status Code After Data Generation

Note

Default status codes are not http status codes.

5.1.2. WSDL Service File Upload

5.1.2.1. Upload a Single WSDL Service File

1. Select the File Type drop-down, select option WSDL/Zip file.
2. Click Choose File to upload WSDL file stored locally on your computer.

Fig. 5.11 Single WSDL File Upload

3. Click Submit. The added wsdl service will be displayed on the service panel on the left.

Fig. 5.12 Single WSDL File

5.1.2.2. Upload a Zip File

Upload a compressed file that contains .wsdl file and its dependencies. When a user uploads a zip file, a drop-down will appear that will display the wsdl master file with the extension .wsdl.

To demonstrate the wsdl zip file upload, we have considered a zip file named manageAccount.zip which contains the master manageaccount_1_0.wsdl file.

1. From the File Type drop-down, select option WSDL/zip file.
2. Click Choose File to upload a zip file.
3. On uploading the zip file, a drop-down appears. Select the master file manageaccount_1_0.wsdl.

Fig. 5.13 Zip Wsdl File Upload

4. Click Submit. The added service will be displayed on the service panel on the left.

Fig. 5.14 Zip Wsdl Service

5. Click on a service/project name.
6. Click the drop-down to display the list of resources under that service. In the below image, manageaccount_1_0.wsdl is the service name, createAccount is the resource name.

Fig. 5.15 Resource Name

7. Click the delete icon corresponding to the service name, to delete the service.
8. On successful upload of wsdl files, click the service name to display the request and response parameters on the Config Data page.

Fig. 5.16 Request and Response Parameters for WSDL

9. To view all the request and response parameters, scroll to the end of the Config Data page. The request and response parameters consists of Variable Name, Variable Type, Source and Function Name.

Below table describes each field in detail.

Table 5.2 Request and Response

Request/Response fields	Description
Variable Name	Refers to the attribute name contained in the uploaded service file
Variable Type	Type of the variable
Source	Refers to the source of generating the mock data
Function Name	Refers to the function associated with the attribute name

On the Config Data page, for each method, the response code that will be returned by the server is also displayed. The user has to compulsorily define a fault code (wherever applicable) before data generation, otherwise data will not get generated.

Fig. 5.17 Sample Fault Code Before Data Generation

Fault code allows the user to define a common structure for an error code. Once the fault code is defined, irrespective of any action performed by the user, the system will throw this fault code after data generation. The fault code (wherever applicable) will be displayed along with other response codes.

Fig. 5.18 Sample Fault Code Code After Data Generation

5.2. Generating Sample Records

5.2.1. Swagger

Mock data (sample request and response) can be generated at service, resource and method level. Users can generate mock data either for all resources or selective resources, and all methods or a selective methods.

Generating Mock Data at Service Level

At service level, mock data is generated for the entire service, i.e for all resources.

1. To generate mock data at service level, click the required service name on the service panel.

Fig. 5.19 Service Panel

2. In the Enter number of request/response need to generate box, enter the number of sample records of swagger mock data that you wish to generate.

Fig. 5.20 Service Level Data Generation

3. If swagger file contains default response, data will not be generated unless default status codes (wherever applicable) is defined. To define a default status code, from the Status Code drop-down, select the required status code. You can select multiple status codes by clicking the check box corresponding to the required status code. Use the Search box to search for a status code.

Fig. 5.21 Default Status Code

4. Click Generate. The sample mock data is generated.
5. Click on a resource name under a service in the service panel to view the sample mock data. Sample Data page displays the sample request, response, headers and the URL information. The endpoint URL can be used on a third party client to consume the API. Further, click on each method to view the sets of mock data under that method.

Fig. 5.22 Swagger Mock Data

The generated mock data is grouped and numbered based on the status code. The number of sets of mock data generated under each status code is also displayed. Click the accordion tab of any status code to hide/show the mock data sets under that status code.

Fig. 5.23 Status Code tab

Note

• If data is generated for all resources, Config Data page will display “Data is generated for all resources” message.
• If data is generated for selective resources, Config Data page will display “Data is generated partially” message.
• If no data is generated, Config Data page will display “No data is generated” message.

Generating Mock Data at Resource Level

At resource level, mock data is generated for selective resources.

1. To generate mock data at resource level, click on a service name on the service panel.

Fig. 5.24 Service Panel

2. In the Enter number of request/response need to generate box, enter the number of sample records of swagger mock data that you wish to generate.
3. From the All Resources drop-down, select the check boxes corresponding to the resources for which you want to generate mock data. Use the Search box to search for a resource.

Fig. 5.25 Select Resources

4. If swagger file contains default response, data will not be generated unless default status codes (wherever applicable) is defined. To define a default status code, from the Status Code drop-down, select the required status code. You can select multiple status codes by clicking the check box corresponding to the required status code. Use the Search box to search for a status code.

Fig. 5.26 Default Status Code

5. Click Generate. The sample mock data is generated based on the resources selected.
6. Click on a resource name under a service in the service panel to view the sample mock data. Sample Data page displays the sample request, response, headers and the URL information. The endpoint URL can be used on a third party client to consume the API. Further, click on each method to view the sets of mock data under that method.

Fig. 5.27 Swagger Mock Data

The generated mock data is grouped and numbered based on the status code. The number of sets of mock data generated under each status code is also displayed. Click the accordion tab of any status code to hide/show the mock data sets under that status code.

Fig. 5.28 Status Code tab

Generating Mock Data at Method Level

At method level, mock data is generated for selective methods under a particular resource.

1. To generate the mock data at method level, click on a service name and then click the required resource name.

Fig. 5.29 Service Panel

2. In the Enter number of request/response need to generate box, enter the number of sample records of swagger mock data that you wish to generate.
3. From the All Methods drop-down, select the check boxes corresponding to the methods for which you want to generate mock data. Use the Search box to search for a method.

Fig. 5.30 Select Method

4. If swagger file contains default response, data will not be generated unless default status codes (wherever applicable) is defined. To define a default status code, on the Config Data page, from the Status Code drop-down, select the required status code. You can select multiple status codes by clicking the check box corresponding to the required status code. Use the Search box to search for a status code.

Fig. 5.31 Default Status Code

5. Click Generate. The sample mock data is generated.
6. Click on a method name under a resource to view the sample mock data. Sample Data page displays the sample request, response, headers and the URL information. The endpoint URL can be used on a third party client to consume the API.

Fig. 5.32 Swagger Mock Data

The generated mock data is grouped and numbered based on the status code. The number of sets of mock data generated under each status code is also displayed. Click the accordion tab of any status code to hide/show the mock data sets under that status code.

Fig. 5.33 Status Code Tabs

Editing a Swagger Mock Data:

Edit option allows you to edit swagger mock data at stub level. Edit option is available for each set of mock data generated.

1. For a particular set of swagger mock data, click the edit icon to edit the mock data. You can edit the path parameter values of the URL, request headers, response headers, request body and response body.

Fig. 5.34 Swagger Edit

2. Click the save icon to save the changes.

Note

• Edit feature for Swagger mock data is applicable for both JSON and XML requests and responses.
• You can only modify the value and not the key of a request/response.
• For a key-value pair, if the variable type is a number, you must enter a number as a value. If a string is entered as a value instead of a number, then the system will throw an error.
• You cannot make changes to any other data in the URL, except the path parameter values.

Deleting a Swagger Mock Data:

Delete option allows you to delete swagger mock data at stub level. Delete option is available for each set of mock data generated.

1. For a particular set of swagger mock data, click the delete icon to delete the mock data.

Fig. 5.35 Swagger Delete

2. A message is displayed asking you to confirm the deletion.

Fig. 5.36 Swagger Delete

3. Click OK to delete the data set or click Cancel to not delete the data set.

5.2.2. WSDL

Mock data (sample request and response) can be generated at service and resource level. Users can generate mock data either for all resources or selective resources.

Generating Mock Data at Service Level

At service level, mock data is generated for the entire service, i.e for all resources.

1. To generate the mock data, at service level, click the required service name on the service panel.

Fig. 5.37 Service Panel

2. In the Enter number of request/response need to generate box, enter the number of sample records of wsdl mock data that you wish to generate.

Fig. 5.38 Service Level Data Generation

3. If wsdl file contains error codes, data will not be generated unless fault codes (wherever applicable) is defined. To define a fault code, from the Fault Code drop-down, select the required fault code. You can select multiple fault codes by clicking the check box corresponding to the required fault code. Use the Search box to search for a fault code.

Fig. 5.39 Fault Code

4. Click Generate. The sample mock data is generated based on the resources selected.
5. Click on a resource name under a service in the service panel to view the sample mock data. Sample Data page displays the sample request, response, headers and the URL information. The endpoint URL can be used on a third party client to consume the API.

Fig. 5.40 Wsdl Mock Data

The generated mock data is grouped and numbered based on the status code. The number of sets of mock data generated under each status code is also displayed. Click the accordion tab of any status code to hide/show the mock data sets under that status code. Fault code is also displayed for error codes wherever applicable.

Fig. 5.41 Fault Code

Note

• If data is generated for all resources, Config Data page will display “Data is generated for all resources” message.
• If data is generated for selective resources, Config Data page will display “Data is generated partially” message.
• If no data is generated, Config Data page will display “No data is generated” message.

Generating Mock Data at Resource Level

At resource level, mock data is generated for selective resources.

1. To generate the mock data at resource level, click on a service name on the service panel.

Fig. 5.42 Service Panel

2. In the Enter number of request/response need to generate box, enter the number of sample records of wsdl mock data that you wish to generate.
3. From the All Resources drop-down, select the check boxes corresponding to the resources for which you want to generate mock data. Use the Search box to search for a resource.

Fig. 5.43 Select Resources

4. If wsdl file contains fault response, data will not be generated unless fault codes (wherever applicable) is defined. To define a fault code, from the Fault Code drop-down, select the required fault code. You can select multiple fault codes by clicking the check box corresponding to the required fault code. Use the Search box to search for a fault code.

Fig. 5.44 Fault Code

5. Click Generate. The sample mock data is generated based on the resources selected.
6. Click on a resource name under a service in the service panel to view the sample mock data. Sample Data page displays the sample request, response, headers and the URL information. The endpoint URL can be used on a third party client to consume the API.

Fig. 5.45 Wsdl Mock Data

The generated mock data is grouped and numbered based on the status code. The number of sets of mock data generated under each status code is also displayed. Click the accordion tab of any status code to hide/show the mock data sets under that status code.

Fig. 5.46 Fault Code

Note

WSDL method is always POST, hence the data generation occurs only at service level and resource level.

Editing a WSDL Mock Data

Edit option allows you to edit wsdl mock data at stub level. Edit option is available for each set of mock data generated.

1. For a particular set of wsdl mock data, click the edit icon to edit the mock data. You can edit the path parameter values of the URL, request headers, response headers, request body and response body.

Fig. 5.47 Wsdl Edit

2. Click the save icon to save the changes.

Note

• You cannot make changes to any other data in the URL, except the query and path parameter value.
• You will not be able to edit fault codes unless they match any of the fault codes defined in the Fault Code dropdown.

Deleting a WSDL Mock Data:

Delete option allows you to delete wsdl mock data at stub level. Delete option is available for each set of mock data generated.

1. For a particular set of wsdl mock data, click the delete icon to delete the mock data.

Fig. 5.48 Wsdl Delete

2. A message is displayed asking you to confirm the deletion.

Fig. 5.49 Wsdl Delete

3. Click OK to delete the data set or click Cancel to not delete the data set.

5.3. Delay Functionality

Before mock data is generated, you can set the delay functionality for the response. The delay functionality allows you to set a custom time delay for the response that will be generated. If you set a time delay, the response will only be generated after the time delay specified by you. Delays are set with respect to the http method level.

To set the time delay:

1. Upload a swagger/zip file or wsdl/zip file.

2. Click a service name on the service panel.

3. In the Delay box, enter the time delay in ms.

   

   Fig. 5.50 Delay Functionality

   Note

   The time delay can be set only in milliseconds.

4. Generate the Swagger / WSDL mock data. Once the sample mock data is generated, the endpoint URL can be used on a third party client to get the response. The response will be generated only after the specified time delay.

Note

The time delay must be set before generating the sample records.

5.4. Source

AutoStub allows you to choose the source for generating the mock data for both Swagger and WSDL files using any of the below options.

• Faker
• Mapped Key
• Custom Method

5.4.1. Faker

Faker is a Python package that generates mock data. The library used here is called JSON Schema Faker. When swagger/wsdl files are passed through this library, it will read the swagger/wsdl file and generate mock data.

1. Upload a swagger/zip file or wsdl/zip file.
2. Click on a service name on the service panel.
3. Under the Source column, by default, Faker will be selected in the drop-down.

Fig. 5.51 Faker

4. Under the Function Name column, click the edit icon corresponding to the required faker function.

Fig. 5.52 Faker Edit

A Search Faker Function dialog appears where where the required faker function name can be searched and changed based on the requirements.

Fig. 5.53 Faker Function

5. Use the Search text box to search for the required faker function.
6. Click the required faker function and click Change Current to change the current faker function.

5.4.2. Mapped Key

Mapped key is used for mapping response parameter with the request parameter that has the same data type. After the mapping is done, the value which the user assigns to the mapped request parameter should be reflected in the response body when the API is being consumed. Any change made to the value of the mapped key will be reflected in the response body.

5.4.2.1. Swagger

1. Upload a swagger/zip file.
2. Click on a swagger service name on the service panel.

Fig. 5.54 Parsed Data Swagger

3. To use mapped key as source, for the required Variable Name, select mapped key from the Source drop-down. From Select a Parameter drop-down, select the required parameter to be mapped.

Fig. 5.55 Mapped Key

A “Mapped key successfully updated” message is displayed. Response parameters can only be mapped with the request parameter having same data type. If the same data type is not present, then “No request parameters found of the same type” message is displayed.

4. Generate the Swagger mock data for Swagger files. The mapped request key will be visible in the response body.

Fig. 5.56 Request Parameter Mapped Swagger

The endpoint URL can be used on a third party client to get the response. When the API is being consumed, the value of the mapped request key will be generated in the response.

Fig. 5.57 Request Parameter Mapped Swagger

Note

The mapped request key value will be dynamic.

5.4.2.2. WSDL

1. Upload a wsdl/zip file.
2. Click on a wsdl service name on the service panel.

Fig. 5.58 Parsed Data WSDL

3. To use mapped key as source, for the required Variable Name, select mapped key from the Source drop-down. From Select a Parameter drop-down, select the required parameter to be mapped.

Fig. 5.59 Mapped Key

A “Mapped key successfully updated” message is displayed. Response parameters can only be mapped with the request parameter having same data type. If the same data type is not present, then “No request parameters found of the same type” message is displayed.

4. Generate the WSDL mock data for WSDL files. The mapped key will be visible in the response body.

Fig. 5.60 Request Parameter Mapped

The endpoint URL can be used on a third party client to get the response. When the API is being consumed, the value of the mapped request key will be generated in the response.

Fig. 5.61 Request Parameter Mapped WSDL

Note

The mapped request key value will be dynamic.

5.4.3. Custom Method

Custom Method is used to create custom functions in order to generate dynamic data in the response of a given request. Custom functions created by the user can be assigned to the response parameters. Assigned custom function arguments can be mapped to the request parameters and it will be executed during the API consumption. The user can either create new custom functions or can use the default functions that are predefined in an application.

5.4.3.1. Swagger

1. Upload a swagger/zip file.
2. Click on a swagger service name on the service panel.

Fig. 5.62 Parsed Data Swagger

3. To use custom method as source, for the required Variable Name, select custom method from the Source drop-down.

Fig. 5.63 Custom Method Source

4. From Select a Function drop-down, select the required custom function. The default functions that are displayed in the custom function list are pre-defined in the application and those functions do not contain any arguments. From this drop-down, you can either select from a list of already created custom functions or select Create to create a new custom function.

Fig. 5.64 Custom Function

5. If you select Create, a Create new custom functions dialog box appears for you to create a new function. You can also access the Create new custom functions dialog box by clicking the Custom button at top-left corner of the AutoStub home page.

Fig. 5.65 Custom Function Dialog

6. In the Create new custom functions dialog box, enter the name of the user defined custom function in the Custom function name box.
7. Enter the value to be assigned to the custom function in the Enter function value box.

Fig. 5.66 Custom Function Value

8. Click Save. A “Custom functions created successfully” message is displayed. Click OK to exit. The custom function will be saved and displayed under the List of Custom Actions.

Once the custom functions are created and values have been assigned to them, they need to be mapped to the request parameters. On the Custom Action page, corresponding to the newly created custom function, “Parameters are not mapped. Click on Map.” message is displayed.

Fig. 5.67 Custom Function Mapping

9. On the Custom Action page, for the newly created custom function, click Map to map the custom function arguments to the request parameters. A Map Parameters Custom Action modal opens.

Fig. 5.68 Map Parameters Custom Action

10. The Custom function arguments that are to be mapped are displayed on the left. From Select a Function drop-down, select the required parameter to be mapped for each of the custom function arguments from the drop-down. All the request parameters that are present within a request can be mapped to custom function arguments.

Fig. 5.69 Map Parameters Custom Action

11. Click Save. A “Custom functions created successfully” message is displayed. Click OK to exit. On the Custom Action page, you can hover over the newly created custom function to view their mapped parameters. Parameters are mapped message will also be displayed under the custom function.

Fig. 5.70 Custom Function Mapped

12. Generate the Swagger mock data for Swagger files. The custom function will be visible in the response body.

Fig. 5.71 Request Parameter Mapped

The endpoint URL can be used on a third party client to get the response. When the API is being consumed, the value of the custom function will be generated in the response.

Fig. 5.72 Request Parameter Mapped Swagger

For a Swagger File:

If the same parameter is present in the Swagger request and response, then by default, the response parameter will have the same value as the request parameter.

Fig. 5.73 Same Value in Response

If the same parameter is present in the Swagger request and response and if the user changes the function source (eg. from Faker to Mapped Key/Custom Method) and maps request parameters, then upon generating the mock data, the response parameter can have a dynamic value.

Fig. 5.74 Dynamic Value in Response

If the user changes the function source after mock data generation, then a message is displayed asking the user if they want to rewrite the existing mock data.

Fig. 5.75 Warning

If the user selects OK then mock data will be generated with the values from the changed function source. If the user selects Cancel then the existing mock data will not be re-written.

Note

This message will only be displayed if the user changes the function source after mock data has been generated. If the user changes the function source before mock data generation, no such message is displayed.

5.4.3.2. WSDL

1. Upload a wsdl or zip file that contains .wsdl file and its dependencies.
2. Click on a wsdl service name on left navigation panel to display the request and response parameters on the Config Data page.

Fig. 5.76 Parsed Data WSDL

3. To use custom method as source, for the required Variable Name, select custom method from the Source drop-down.

Fig. 5.77 Custom Method Source

4. From Select a Function drop-down, select the required custom function. The default functions that are displayed in the custom function list are pre-defined in the application and those functions do not contain any arguments. From this drop-down, you can either select from a list of already created custom functions or select Create to create a new custom function.

Fig. 5.78 Custom Function

5. If you select Create a Create new custom functions dialog box appears for you to create a new function. You can also access the Create new custom functions dialog box by clicking the Custom button at top-left corner of the AutoStub home page.

Fig. 5.79 Custom Function Dialog

6. In the Create new custom functions dialog box, enter the name of the user defined custom function in the Custom function name box.
7. Enter the value to be assigned to the custom function in the Enter function value box.

Fig. 5.80 Custom Function Value

8. Click Save. A “Custom functions created successfully” message is displayed. Click OK to exit. The custom function will be saved and displayed under the List of Custom Actions.

Once the custom functions are created and values have been assigned to them, they need to be mapped to the request parameters. On the Custom Action page, corresponding to the newly created custom function, “Parameters are not mapped. Click on Map.” message is displayed.

Fig. 5.81 Custom Function Mapping

9. On the Custom Action page, for the newly created custom function, click Map to map the custom function arguments to the request parameters. A Map Parameters Custom Action modal opens.

Fig. 5.82 Map Parameters Custom Action

10. The Custom parameters that are to be mapped are displayed on the left. From Select a Parameter drop-down, select the required parameter to be mapped for each of the custom function arguments from the drop-down. All the request parameters that are present within a request can be mapped to custom function arguments.

Fig. 5.83 Map Parameters Custom Action

11. Click Save. A “Custom functions created successfully” message is displayed. Click OK to exit. On the Custom Action page, you can hover over the newly created custom function to view their mapped parameters. Parameters are mapped message will also be displayed under the custom function.

Fig. 5.84 Custom Function Mapped

12. Generate the WSDL mock data for WSDL files. The custom function will be visible in the response body.

Fig. 5.85 Request Parameter Mapped

The endpoint URL can be used on a third party client to get the response. When the API is being consumed, the value of the custom function will be generated in the response.

Fig. 5.86 Request Parameter Mapped WSDL

5.4.3.3. Editing/Deleting a Custom Function

You can edit or delete a custom function using the edit or delete icon in the Create new custom functions dialog box.

To open the Create new custom functions dialog box, select Create from the Select a Parameter drop-down. You can also access the Create new custom functions dialog box by clicking the Custom button at top-left corner of the AutoStub home page.

Fig. 5.87 Custom Button on Home Page

On the Create new custom functions dialog box, you can edit or delete a custom function using the edit or delete icon.

Fig. 5.88 Custom Function Edit/Delete

Editing a Custom Function

1. To edit a custom function, click the edit icon corresponding to the custom function you want to edit. The custom function opens for editing.

Fig. 5.89 Custom Function Edit

2. If the custom function is assigned to a parameter, a warning message appears as shown below.

Fig. 5.90 Custom Function Edit

3. Click OK to exit. You must remove the custom function from the parameter associated to it before deleting the function. Once the custom function is detached, click icon corresponding to the custom function.
4. After making the required modifications, click Update to save the changes. Custom function will be updated successfully.

Note

You cannot edit the default functions.

Deleting a Custom Function

Custom functions that are not assigned to a parameter can be deleted. If a custom function is assigned to one or more parameters of a service, that function needs to be detached from those parameters in order to delete it.

1. To delete a custom function, click the delete icon corresponding to the custom function you want to delete. If the custom function is assigned to a parameter, a warning message appears as shown below.

Fig. 5.91 Custom Function Delete

2. Click OK to exit. You must remove the custom function from the parameter associated to it before deleting the function. Once the custom function is detached, click icon corresponding to the custom function. A warning message appears as shown below.

Fig. 5.92 Custom Function Delete

3. Click OK to delete the function or Cancel to exit.

Note

You cannot delete the default functions.

5.5. Consuming the APIs

5.5.1. Working with Strict Mode

For validation purposes, Strict Mode feature has been introduced. Strict mode validates each and every detail of the request. It throws an exception if the request is invalid.

5.5.1.1. Swagger

1. Upload a swagger/zip file that contains .json file(s) and its dependencies.
2. Generate the Swagger mock data.
3. At the top of the Sample Data page, click the Strict mode toggle button to turn it to green and turn ON the strict mode. Inversely, click the Strict mode toggle button to turn it to red and turn OFF the strict mode.

Note

By default the strict mode will be switched ON. Upon disabling it, random responses will appear for the request.

Fig. 5.93 Swagger Strict Mode

4. To consume the API from a third party client in strict mode, follow the below steps:

   1. Click the copy icon to copy the request URL from the application.
   2. Open a third party client.
   3. Paste the request URL at the required place in the third party client.
   4. Set the type of method (GET/PUT/POST/DELETE/PATCH).
   5. Set the key-value pairs for the HTTP headers.
   6. Click the copy icon to copy the request body from the application.
   7. Paste the request body at the required place in the third party client.
   8. Generate the response.

   Note

   To get a response via strict mode, it is mandatory to pass the request body in the third party client.

Fig. 5.94 Third Party Client Response for Swagger Example

Note

To get a swagger response, you must enter the “required” parameters in the request body even when strict mode is disabled. However, the value of the “required” parameter is not validated. ”Optional” parameters need not be entered when strict mode is disabled as they are not validated when strict mode is switched off.

5.5.1.2. WSDL

1. Upload a wsdl/zip file that contains .wsdl file and its dependencies.
2. Generate the WSDL mock data.
3. At the top of the Sample Data page, click the Strict mode toggle button to turn it to green and turn ON the strict mode. Inversely, click the Strict mode toggle button to turn it to red and turn OFF the strict mode.

Note

By default the strict mode will be switched ON. Upon disabling it, random responses will appear for the request.

Fig. 5.95 WSDL Strict Mode

4. To consume the API from a third party client in strict mode, follow the below steps:

   1. Click the copy icon to copy the request URL from the application.
   2. Open a third party client.
   3. Paste the request URL at the required place in the third party client.
   4. Set the type of method (GET/PUT/POST/DELETE/PATCH).
   5. Set the key-value pairs for the HTTP headers.
   6. Click the copy icon to copy the request body from the application.
   7. Paste the request body at the required place in the third party client.
   8. Generate the response.

   Note

   To get a response via strict mode, it is mandatory to pass the request body in the third party client.

Fig. 5.96 Third Party Client Response for WSDL Example

Note

For WSDL files, request body parameter values are not validated if strict mode is switched off.

5.5.2. Viewing Transaction Logs for an API

Transaction logs is a record of all the transaction parameters encountered while consuming an API, such as url, methods, request, response data etc. The transaction data will be available in the user’s system’s home directory. The transaction logs will be stored in separate files based on the log level configuration. For example, application logs and transaction logs will be stored in separate files.

1. Upload a swagger/zip file or wsdl/zip file.
2. Click on a service.
3. Generate the Swagger / WSDL mock data. After mock data is generated, the transaction logs will be available. The transaction log which is stored in the file in user’s home directory will give the transaction information in detail.

Example of a transaction log is given below.

2020-07-28T13:22:21.671 : [TRANSACTIONDATA] : 039a2df0-3b88-49b5-890a-3be5ebae512a : 1668:testSwag/handlers/1668-229/postWith.json/industry/levels.js:postWith.json:/industry/levels:{"method":"post","statusCode":"200","resourceData":{"url":"http://192.168.43.249:3001/1668-229/v2/industry/levels","requestBody":{"Member":{"id":"53700","category":{"id":"34698","name":"River Renner"},"name":"doggie","photoUrls":"http://lorempixel.com/640/480","tags":{"id":"6205","name":"August Wolff"},"status":"delivered"}},"responseHeaders":{"x-response-code":"AERTUY67675KJL"},"responseBody":{"Pet":{"x-response-code":"AERTUY67675KJL","id":"53700","petId":"43994","quantity":"62626","shipDate":"2020-10-13T06:35:18.192Z","status":"delivered","complete":"false"}}}}

The following details can be retrieved from the above transaction log:

Fig. 5.97 Transaction Logs

5.5.3. Viewing Headers

There are two types of headers supported by the AutoStub application for Swagger 2.0 specification for both Swagger and WSDL files.

1. Custom Headers
2. HTTP Headers

5.5.3.1. Custom Headers

Custom Header support is provided in AutoStub to consume the APIs based on Swagger 2.0 specifications. Custom Headers are used for providing additional information about an API (ex: security). Users can include header parameters in the request which will be passed to the server to get the appropriate response. The data will be generated for header parameters and displayed in the response body. If the user does not pass a custom header along with the request body, they will not be able to consume the API, that is, the response body is not sent.

5.5.3.1.1. Swagger

1. Upload a swagger/zip file.
2. Click on a swagger service. Parsed data that contain the header parameters is displayed.

Fig. 5.98 Parsed data with Header Parameters for Swagger

3. Generate the Swagger mock data.
4. On the service panel, click a swagger service name and then click the type of method for which you want to view the sample request and response. The mock data with custom headers are displayed for a particular API.

Fig. 5.99 Custom Headers for Swagger

5.5.3.1.2. WSDL

1. Upload a wsdl/zip file.
2. Click on a wsdl service. Parsed data for wsdl is displayed.

Fig. 5.100 Parsed data for WSDL

3. Generate the WSDL mock data.
4. On the service panel, click a wsdl service name and then click the resource for which you want to view the sample request and response. The mock data with custom headers are displayed for a particular API.

Fig. 5.101 Custom Headers for WSDL

5.5.3.2. HTTP Headers

A swagger file with 2.0 specifications has two parameters called Consumes and Produces. Consumes specifies the request body content type ( application/json for JSON and application/xml for XML) while Produces specifies the response body content type ( application/json for JSON and application/xml for XML) that is configured for a particular API. Based on the Content-Type data will be displayed in the UI. If in the initial position Content-Type is JSON then JSON will be displayed in UI. If in the initial position Content-Type is XML then XML will be displayed in UI.

HTTP Headers are of two types: Content-Type and Accept.

Accept Headers lets the server know what content types (JSON/XML) will be accepted in the response. Content Type headers lets the server know what content types (JSON or XML) will be returned in the response.

While consuming the API in a third party client, if the Accept Header in the request header is specified as application/json, Content Type is specified as application/json and a JSON request body is passed, then we will get the response in JSON format. Similarly if the Accept Header in the request header is specified as application/xml, Content Type is specified as application/xml and an XML request body is passed, then we will get the response in XML format.

Note

HTTP headers are currently not implemented for WSDL.

5.5.3.2.1. Swagger

1. Upload a swagger/zip file.
2. Click on a swagger service. Parsed data that contains the header parameters is displayed.

Fig. 5.102 Parsed data with header parameters for Swagger

3. Generate the Swagger mock data.
4. On the left navigation panel, click a swagger service name and then click the type of method for which you want to view the sample request and response. The Accept Header and Content Type Header parameters are displayed for a particular API.

Fig. 5.103 Header Parameters for Swagger