Calling Methods via Configurable Web Services
In previous blog posts, we’ve covered how to set up a Configurable Web Service (CWS) within Aras Innovator®. In this post, we will cover a way to extend the functionality of a CWS endpoint by calling a server method. Creating our Method To start, we will need to create the server Method that will be called via our CWS endpoint. In this example, we will be creating a new endpoint for registering Alternate parts. If a user passes in a Part Number for a part, and a Part Number for an alternate part, this method will create a Part Alternate relationship between the two. Log in as an admin Navigate to TOC -> Administration -> Methods Create a new method with the method code below gist.github.com/christophersgillis/f25bfd73feb7148715a44d72ac01e880 Save and close the Method Note that at the start of this method we are retrieving two properties: the base_part_number and an alternate_part_number. When we make our web service below, we will configure the method endpoint to accept these two parameters. Defining our CWS Web Service Now that we have our Method defined, we can configure our CWS service such that we can call this Method from it. Log in as an admin Navigate to TOC -> Administration -> External Access -> Web Services Create a new CWS web service Title: Parts Management Endpoint Name: PartsManagement Click save and now configure a new endpoint related to this web service Instead of clicking Add ItemTypes as you might have done following our previous blogs, click Add Global Methods Search for and select the method we created above The Alias here will determine what the actual URL will be, so set the Alias to AddPartAlternate We’ll also add two parameters to match what the method is expecting: the base_part_number and alternate_part_number Save both the endpoint and the web service and open Postman for testing Calling our Method With Postman open, we can set up the sample call we will be using to test our new Method endpoint. If you’ve been following along, your request should look something like the screenshot below. Note that because this is a Method endpoint, the request type should always be POST. After configuring the Authorization for the request (either using an API Key or authenticating via OAuth), we should be able to click send and see that our Part Alternate was successfully added! This is just one example of the ways that we can leverage server methods to make our CWS endpoints even more valuable. Let us know if there are any business needs that this functionality would be useful to address. We hope you will be joining us at this year’s ACE Tech Summit March 31, 2025 from 9:00 AM – 4:30, followed by a reception. Details and registration information may be found here.
Consuming CWS Endpoints in Aras Innovator
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.
