My previous blog reviewed how to configure a simple Web Service using Configurable Web Services. This companion blog will use the same example created in my previous blog and go over how to submit requests to the Web Service you created. It will be similar to previous blogs about authenticating with and utilizing our Rest API. We’ll be using Postman to execute our requests, but you can also use this method to communicate with Aras Innovator from your own custom applications.

API Key vs Oauth

In the previous blog, I showed how you could generate an API Key for your Web Service. I want to take a moment to say that while those are useful, they should not be used except in unique circumstances. The biggest reason is the lack of traceability. When external systems are accessing or modifying your Aras Innovator instance, you want a record of who is making those transactions. For custom applications, you should be authenticating via OAuth, as we will in this post. API Keys are intended for use in cases where a server-to-server connection is being made, and you wouldn’t be worried about who is committing that action. An example would be an Azure service called s called automatically and programmatically. The API Key would be the better option there as a user wouldn’t be responsible for the transaction.

An Example – Launching Postman

Since we’ve already created our Web Service, the next step is to launch Postman. If you’re unsure how to use/authenticate with Postman, take a look at these two blogs on authenticating and utilizing our Rest API.

The format for querying your Web Service is exactly the same as using our OData endpoint. Using OData, a request for all parts looks like this:

http://localhost/31demo/Server/Odata/Part

Querying our new endpoint looks like this:

http://localhost/31demo/Server/ws/partBom/v1/Part

The URL you use is specific to your Endpoint, and of course, you can have multiple. You can find the URL in the Endpoints tab of your Web Service. It’s also important to note that you can use all the same tricks to get specific data that you can use in the OData endpoint.

Things like filtering, getting specific items, and querying relationships all work. Here’s an example of the part output.

 

The only things that are returned from your query are the things you defined in your Web Service. If you try to get Documents without including them in your Endpoint, you’ll see the following result.

This is very powerful, allowing you to ensure that only the required data is exposed. A great example of this would be if you wanted to create an external application that queries Aras Innovator®. You’d want to limit the app’s access to avoid potential security issues.

That was a quick demonstration of how you can consume your Configurable Web Services. I highly recommend playing around with the Endpoint editor to see if it could suit the needs of your external applications.