Improvements in Configurable Web Services & Responsive Forms in Aras Innovator 32
In Aras Innovator® Release 32, we’ve made some important changes to two of our newest features. Responsive Forms and Configurable Web Services have seen enhancements that improve usability and reliability. Responsive Forms As one of the newest additions to Aras Innovator, we’re continuously working on improving Responsive Forms. With our newest release, we’ve added low-code logic that allows you to color the background, element, or text of your fields. This had to be managed with code in the past, but now you can use our simple rule editor, which I described in a previous blog. In addition, you can now add Boolean Operators when using multiple rules. This allows for finer control over your forms based directly on the data. This allows us to do things like the following: Responsive Forms can now be used in the Add, View, and Edit view types. This allows you to have different views based on how your users interact with your form. Configurable Web Services (CWS) There are a number of new features in CWS that will make it much easier to use for different use cases. One of the biggest ones is an easier File Upload. A new Upload Endpoint allows you to upload files with a single request, as opposed to the multi-step process from before. In addition, we’ve enabled developers to execute transactions in batches for both the REST API and CWS. This will reduce the number of server calls while improving transaction rollback if a request fails. Finally, for CWS, we’ve added the ability to allow specific API Keys to overwrite system properties. This needs to be handled very carefully but allows for powerful connections to external systems. It will be very useful when pulling items from other systems to federate them in Aras since you can do things like overwrite when an Item is created to match the value in the external system. This can be configured under the API Keys relationship in your CWS: These changes to two of our newest features are just the beginning. We’ve got some really exciting things coming in the pipeline. Please try out some of these new features and let us know how you like them on the forums. We’d love to hear some feedback and what we could do to better meet your needs.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.
