[b][u]To Support;[/u][/b] Could you please upgrade the whole REST API system to accommodate "[b][u]Standard[/u][/b]" API that works with Aware's security and covers all the [b][u]REST Verbs[/u][/b] that all the client systems, i.e. Angular, Kendo, Bootstrap and other JS library use to communicate to backend REST API. I have a potential client who wants to build the entire backend system in Aware and expose data and functionalities to other insurance agencies via REST API. This means a complete stateless backend system that any client can call to fetch data, without maintaining any state. This feature can really make Aware as an attractive and fast backend development. Thanks!

I must agree... a restful API builder within aware would be an awesome addition.... it seems like every client needs/wants to interface with some other system they use. Soap isn't an option.

[quote="RLJB"]I must agree... a restful API builder within aware would be an awesome addition.... it seems like every client needs/wants to interface with some other system they use. Soap isn't an option.[/quote] Lack of "[b]Standard[/b]" REST API that all the new clients need to use, comes up with every prospect I run into recently. This is the third prospect in "Insurance" industry, where Insurance companies need to expose their data and functionalities to "Brokers & Agents". Lots of Brokers develop their own middle tier apps that talk to different insurance systems via REST API, then they can produce their data to agents and clients. Aware is a perfect product to build backend systems for insurance Brokers & agents who can design their own forms to get/set data to Aware's system via STANDARD REST API. The current Aware's REST API, is the old fashion RPC that is no longer used by current market. [b][u]Secondly, Aware needs to incorporate the authorization and security as part of each API call without using stateful system, so it will make Aware more scale-able.[/u][/b] Other similar products to Aware, have ALL shifted to STANDARD REST API to allow developers to build backend system that any client can consume. I really hope this becomes the main focus of 8.1. I've been asking about this since version 5.9 in 2014. :(

Hmmm ... getting all biblical up in here. And on the 8th version (ok 8.1), it will be the day of REST. I hope the AwareIM "man upstairs" is listening.

[quote="johntalbott"] I hope the AwareIM "[b]man upstairs[/b]" is listening.[/quote] Every day, I'm going to church and praying... :D

I must be missing something (as usual!). I see Aware's huge plus not in the backend database logic (more on this later) but in the ease, and speed, and flexibility of the Aware UI. The Visual Perspectives, built in security, queries, forms, menus, etc, etc. are the main reason why I adopted Aware for my development. REST is usually used for CRUD (Create, Read, Update, Delete) processing. Lets talk about each of these. Aware does a SELECT * for all of the table columns and related tables. Perhaps you won't see much of a difference on a LAN, but for a mobile device, I would much rather have a Stored Proc (or query) that is just transmitting the required columns on the LAN. Creates, Updates and Deletes (the other 75%) of CRUD are easy - peazy to write in SQL (and once written can be copied so for your next BO, just change the name of the underlying table and all is good). I don't see any plus of Aware doing this. Yes, I do understand that Aware Rules are UBER-AWESOME. I am adding a payment entry process to my system, and when a payment is entered / changed, my simple rules makes sure that the Invoice file is updated, the Customer file is updated. ) That logic would have to be written in all of the Payment CRUD procedures. This DOES add complexity to those and I can see that as a prime reason to want to use Aware for the REST Server. As far as Aware Processes, so many have a UI component (Report Error or Display Message ) So they would be useless to use as a REST Server. If they are just doing Database manipulation, that would be so much faster and more efficient using a SP. Other Issues. I do not write any process to just UPDATE a BO without starting with a form. So, if I am updating my Payments, I open a form, and the update happens when the user clicks the Save button. (Yea, it might call a process to update other tables, but not the main BO) I am not sure how you could write a process to do that, assuming you have the UI handled by other front ends. I "Guess" you would have to have a "ReadBO" process that would return all of the attributes (there are at least 2 that you and I never see, that Aware uses for "locking" the BASVERSION and BASTIMESTAMP). and then you would have to have an UpdateBO process where you can send the entire record with the updates back to Aware. Maybe there is another way. Not sure. BTW, I am using Node for a REST Server for applications that I wrote using Sencha EXTJS. So I am very familiar with REST. (Of course, a HUGE advantage of using Node is the extensibility with 1,000's of free add-on modules. I have ones that connect to a credit card processor, ones for logging, etc.) So please educate me as to the benefits of using AwareIM as a REST Server. Bruce

[quote="BLOMASKY"] REST is usually used for CRUD (Create, Read, Update, Delete) processing. Lets talk about each of these. Aware does a SELECT * for all of the table columns and related tables. Perhaps you won't see much of a difference on a LAN, but for a mobile device, I would much rather have a Stored Proc (or query) that is just transmitting the required columns on the LAN. [/quote] The Select * is between the DB to the AIM app server, so it's all server side. I still don't love it, but all columns are not being surfaced in the UI. In any event, this is fixable. [quote="BLOMASKY"] Yes, I do understand that Aware Rules are UBER-AWESOME. I am adding a payment entry process to my system, and when a payment is entered / changed, my simple rules makes sure that the Invoice file is updated, the Customer file is updated. ) That logic would have to be written in all of the Payment CRUD procedures. This DOES add complexity to those and I can see that as a prime reason to want to use Aware for the REST Server. [/quote] What you said here is the reason. The idea is to have the option of completely decoupling the UI from the app server. While I get it it's easy to let AIM build the UI .. it's not always the best way to go ... and from a "developer" standpoint ... it's an 'anti-best practice". For a very customized UI, it would be simpler to build the UI independent of the data source. It opens the door to using many other UI libraries ... AngularJS, Aurelia, ReactJS as they were intended. AIMr's could squeeze a lot more juice out of Kendo UI, if we could could easily leverage standard JSON and/or oDATA produced by an AIM process or query. And the above decoupling is a must from an INTEGRATION standpoint. Meaning that ANY application can consume / use AIM processes to manage the logic versus SQL code. As a simple example .. what if your lumber company client has a business partner that wants to place an order in your AIM system directly from their system via REST. As a result of placing the order, AIM needs to send an email confirmation to the ordering person or others. Are you going to create the email template and logic to send the email in SQL? I absolutely agree with you that there is a time & place for not using AIM rules/processes, but who wants to write plumbing code if it's not necessary?

I'm probably being too simple here, but our clients ask us to... 1. integrate this mailing system (Mailchimp, Campaign Montior, iContact, etc) with their contacts in our AwareIM app.... look up all their docs and they all have Restful Open APIs 2. integrate this accounting system (Xero, MYOB, SAP, Freshbooks, etc) with their Invoices/Stock in AwareIM app.... look up all their docs and they all have Restful Open APIs 3. integrate this POS system (so many here I can't even list them) so we can get sales states into their AwareIM app.... look up all their docs and they all have Restful Open APIs 4. integrate with this CRM/Scanning system/payroll system .... you get the idea... All need the following: 1. oAuth and/or HTTP basic authorization 2. An ability to quickly create JSON payloads from AwareIM BO instances and attributes 3. An ability to POST the above payload with correct headers 4. An ability to expose a webservice that accepts responses and can quickly decode the JSON that comes back into Aware and put it into BOs and attributes Of course there are lots of work arounds to make this possible. We have implemented many of them ourselves, we've written AwareIM functions, and developed a few plugins, and use AWS API Gateway and Lambda functions, it "works" but it isn't all baked/built into Aware - which is what I would like to see. Same with stored procedures, we don't wish to go down that path, we prefer all the configuration is done within aware. We don't even allow some of our junior developers to have access to databases. Aware does do SOAP webservices (and some JSON stuff) and we have deployed them, but in 2016/2017 we've found none (and I mean literally not one - no exaggeration) external system we have been asked to interface with uses SOAP. Vlad has previously mentioned that it's difficult to do a JSON based web-service due to the unstructured nature of the data. He sure knows more than me, so I take his word at 110% correct. However we're not suggesting to replicate the existing webservice (discover) feature of SOAP in Aware to work with restful APIs. Instead just a few extra functions and tools within in Aware that allow use to achieve items 1 to 4 above as part of the normal "configuration" of aware. Updating a Java plugin, requires a restart of Aware, so it can't be deployed quickly, and it sits as a 'black box' that an aware configurator can't see into.

[quote="RLJB"]I'm probably being too simple here, but our clients ask us to...[/quote] Great post. One thing that I wanted to clarify regarding my original post is that, my request is about "exposing" Aware's resources as in RESTful fashion and not "Consuming" REST services. For that, I understand we have to write java plugins. Hope this clarifies my request.

This topic has been somehow changed from the request to [i]expose [/i]REST services to the request to [i]consume [/i]REST services. These are two completely different things. As we said many times before to our best knowledge there is no industry standard for consuming REST services, so implementing an out-of-the-box solution is very difficult. (Although, this may need to be investigated further). So the current approach is a Java plugin and we have implemented quite a few ourselves that consume REST services for the integration with XERO, AutoCad to name a few. Exposing REST services IS SUPPORTED. So I am not sure what the request is about. If it is about limitations of the current implementation please clearly state what they are.

[quote="aware_support"]This topic has been somehow changed from the request to [i]expose [/i]REST services to the request to [i]consume [/i]REST services. These are two completely different things. As we said many times before to our best knowledge there is no industry standard for consuming REST services, so implementing an out-of-the-box solution is very difficult. (Although, this may need to be investigated further). [/quote] I encourage you to check out info regarding the OpenAPI Specification at http://swagger.io/specification/

V8.1 Feature Request

bkonia

I have used this before to capture web hooks. Once you have setup an Object for Sendgrid and the relevant Sendgrid event attributes and a User so the webhook can log in it works perfectly

I assume you're referring to web hooks in general, not SendGrid specifically, because this will definitely NOT work with SendGrid. The SendGrid web hook communicates via POST, not GET and the data structures are sent as JSON objects, not as query string parameters. Thus, you will receive a notification, but there will be no way to parse the data from the notification.

« Previous Page