Loading Web Services in Libraries

Studio can generate activities directly from SOAP or REST web services, or Postman collections through the Service Editor window.

SOAP and REST Web Services

The window enables you to automatically load all the methods or endpoints in a given web service, be it REST or SOAP, as long as the provided link includes the services' definition - Swagger or WSDL.

Once loaded you select from which endpoints or methods to automatically create activities. All selected items are displayed in the Activities panel, under the Namespace you provided in the Service Editor window.

It is possible to then package these libraries as a .nupkg file and publish it to Orchestrator or to a custom location. As a result, you can easily share your newly-defined activity with other developers that you work with.

Adding Services

Follow the steps below to generate activities from web services:

1. Create a library in Studio, as explained in the About Libraries page.
2. In the Design tab, click New Service, or right-click Services in the Project panel, then click New Service. The Service Editor window is displayed.
   
   

   

   
   
3. Add a file path or link to the Swagger or WSDL resource. Click Load. All defined endpoints from the web service are now loaded in the Service Editor window.
   
   

   

   
   
4. Type in the method or operation you need in the Search Operations search box and view the results below. For Swagger, methods are marked with different colors in each endpoint. Use the Deselect All checkbox to deselects all endpoints and choose the endpoints that you want to load. The namespace is generated automatically, simply type in a new name to change it.
5. Click Save. The service is now integrated in the project tree.
   
   

   

   
   
6. To use the generated activities in the Designer panel, go to the Activities panel, search by the service namespace in the Available activities section and drag each activity to the panel.
   Note:

   For SOAP services, it is recommended to load only SOAP clients, as opposed to HttpGet or HttpPost clients.

   For Swagger services, when the service cannot deserialize the response from the server, it is recommended to inspect the Swagger schema and search for required properties in the model definitions.

To edit a service simply right-click the service in the Project panel, under Services and select Edit Service.

Please note that if your project is under source control, checking out only the library's project.json file enables the Edit Services option for .xaml files with loaded SOAP or REST web services.

Adding and editing a service is also reflected in the project.json file containing the definition of the library, and in the service document. A webServices node is added in the project.json file, and each service is identified by the following elements:

Parameter	Description
namespace	The name of the service provided in the Service Editor window.
serviceDocument	The path to the .json file containing metadata for the SOAP or Swagger service. The file is used when the service is repaired, and should be versioned as part of the project.
webDocumentUri	The file path or link to the Swagger or SOAP resource (provided when the service is created in the Service Editor window).
uniqueReference	A reference needed for versioning the service.

Repairing Services

dll files generated from SOAP or REST web services are not pushed to source control repositories. Therefore, when checking out libraries that contain services, the projects have unresolved activities in the Designer panel.

To repair those activities and regenerate the service .dll file right-click on the service node in the Project panel and select Repair Service from the context menu.

SOAP or REST service metadata and additional information is stored in a .json file for each service loaded in Studio. If a loaded service is missing its associated .json file, the Repair Services context menu option for the Services node enables you to generate the missing .json files using the link to the web document descriptor that was provided when that service was created. As a consequence, filters that might have been applied when the service was first generated are not applied anymore and all the resources provided by the aforementioned path or link are imported.

Publishing libraries using UiPath.Studio.CommandLine.exe command-line user interface detailed in the Mass Update Command Line Parameters page does not take web services into consideration.

Note: Generated activities from SOAP or REST services cannot be localized in Studio.

To call activities generated from web services multiple times inside a loop, create a separate workflow from the main library file, and invoke the service method there. In the main workflow, use the Invoke Workflow File activity inside a For Each activity, and invoke the previously created workflow.

For more details about generated activities from web services, check out this page.

Importing Namespaces

Studio v2020.4 brings a breaking change in terms of libraries with imported Swagger services. The way in which Studio interprets the .json files from Swagger services has changed, thus generating backward compatibility issues if and only if an existing service is edited from the Edit Service window.

In the following example, we've illustrated the change using the Petstore demo web service.

Prior to Studio v2020.4, after adding the service to a library project, and using “Browse for Types…” context menu, the following namespaces are found under SwaggerPetstore assembly name:

Drilling down in UiPath.WebClient._ClientNamespace the following types can be found:

Therefore, if AddPet activity had been used in a xaml file from a Studio library, it would have been part of the UiPath.WebClient._ClientNamespace. The _ClientAddPetRequest type was used for generating a request, like in the excerpt below:

xmlns:uw_="clr-namespace:UiPath.WebClient.<em>ClientNamespace;assembly=SwaggerPetstore" 
...
<uw</em>:AddPetActivity BearerToken="{x:Null}" ClientCertificate="{x:Null}" ClientCertificatePassword="{x:Null}" Headers="{x:Null}" OAuth2Token="{x:Null}" Password="{x:Null}" Username="{x:Null}" DisplayName="AddPet" Endpoint="["https://petstore.swagger.io/v2"]" sap:VirtualizedContainerService.HintSize="200,22.4" sap2010:WorkflowViewState.IdRef="AddPetActivity_1" TimeoutMS="30000">
      <uw_:AddPetActivity.Request>
        <uw_:<em>ClientAddPetRequest Body="{x:Null}" />
      </uw</em>:AddPetActivity.Request>
    </uw_:AddPetActivity>
  </Sequence>
</Activity>

Using Studio v2020.4, the following namespace can be found when importing the same web service:

The following types are found when expanding the UiPath.WebClient.PetClientNamespace:

Therefore, if AddPet activity is used in a xaml file from a Studio library created with v2020.4, it is part of the UiPath.WebClient.PetClientNamespace, and the PetClientAddPetRequest type is used for generating a request. These are different namespaces and types as for libraries created with versions prior to v2020.4.

Below is an excerpt of such a library created with v2020.4:

xmlns:uwp="clr-namespace:UiPath.WebClient.PetClientNamespace;assembly=SwaggerPetstore"
...
<uwp:AddPetActivity BearerToken="{x:Null}" ClientCertificate="{x:Null}" ClientCertificatePassword="{x:Null}" Headers="{x:Null}" OAuth2Token="{x:Null}" Password="{x:Null}" Username="{x:Null}" DisplayName="AddPet" Endpoint="["https://petstore.swagger.io/v2"]" sap:VirtualizedContainerService.HintSize="200,22.4" sap2010:WorkflowViewState.IdRef="AddPetActivity_1" TimeoutMS="30000">
      <a href="uwp:AddPetActivity.Request">uwp:AddPetActivity.Request</a>
        <uwp:PetClientAddPetRequest Body="{x:Null}" />
      </uwp:AddPetActivity.Request>
    </uwp:AddPetActivity>
  </Sequence>
</Activity>

Postman Collections

The Postman application can be used for creating and grouping API definitions into collections, thus organizing and chaining your requests together. Postman supports scripts for passing data between API requests. Check out the Postman online documentation to learn about creating a collection.

If you already have a Postman collection, you can load its requests in Studio, and generate an activity. Maintenance of the collection is done in Postman, and any changes are exerted in your workflow as well.

Studio receives access to a Postman collection through an API key, which must be added to the Service Editor window, in the File or Link field. The API key is an account-wide key generated from the Postman profile settings > API keys page and not an API key generated by sharing a collection. Therefore, modifications to requests are done only in Postman and not in Studio as well.

Studio loads all requests defined in the collection, and requests cannot be executed individually. Editing and repairing a collection in Studio is done in the same way as for SOAP or REST web services.

Prerequisites for Postman Collections

• Nodejs and NodeJS CLI, version 6
• Newman version 4.5.5

It is recommended to restart your machine after installing Newman.

Example with a Postman Collection

The following example uses a Postman collection to get the value of a certain currency and displays it in Studio's Output panel.

In this example, we wrote a test scrip to iterate through the received data. We declared a global variable directly in the script, but this can also be done with the Set a global variable snippet in Postman, read more about this here.

The In argument passed the currency EUR value to an Out argument, visible in the library, in the Properties panel > Input > Collection. The Out argument is visible in the same panel, in the Output section.

Out arguments from the activities are mapped to a variable and its value is written to the Output panel.

You can use an If activity to validate the variable's returned value. In this example, we validated that the value is returned, and then wrote it to the Output panel.