V8.1 Feature Request

If you have questions or if you want to share your opinion about Aware IM post your message on this forum
BenHayat
Posts: 2749
Joined: Thu Dec 23, 2010 5:48 am
Location: Fla, USA
Contact:

V8.1 Feature Request

Post by BenHayat »

To Support;

Could you please upgrade the whole REST API system to accommodate "Standard" API that works with Aware's security and covers all the REST Verbs 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!
RLJB
Posts: 914
Joined: Tue Jan 05, 2010 10:16 am
Location: Sydney, Australia

Re: V8.1 Feature Request

Post by 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.
Rod. Aware 8.6 (latest build), Developer Edition, on OS Linux (Ubuntu) using GUI hosted on AWS EC2, MYSQL on AWS RDS
BenHayat
Posts: 2749
Joined: Thu Dec 23, 2010 5:48 am
Location: Fla, USA
Contact:

Re: V8.1 Feature Request

Post by BenHayat »

RLJB wrote: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.
Lack of "Standard" 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. 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.

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. :(
Last edited by BenHayat on Wed May 03, 2017 1:34 pm, edited 1 time in total.
johntalbott
Posts: 619
Joined: Wed Jun 17, 2015 11:16 pm
Location: Omaha, Nebraska
Contact:

Re: V8.1 Feature Request

Post by johntalbott »

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.
VocalDay Solutions - Agility - Predictability - Quality

We specialize in enabling business through the innovative use of technology.

AwareIM app with beautiful UI/UX - https://screencast-o-matic.com/watch/crfUrrVeB3t
BenHayat
Posts: 2749
Joined: Thu Dec 23, 2010 5:48 am
Location: Fla, USA
Contact:

Re: V8.1 Feature Request

Post by BenHayat »

johntalbott wrote: I hope the AwareIM "man upstairs" is listening.
Every day, I'm going to church and praying... :D
BLOMASKY
Posts: 1470
Joined: Wed Sep 30, 2015 10:08 pm
Location: Ocala FL

Educate me pls for the rational of having Aware be a REST Se

Post by BLOMASKY »

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
johntalbott
Posts: 619
Joined: Wed Jun 17, 2015 11:16 pm
Location: Omaha, Nebraska
Contact:

Re: Educate me pls for the rational of having Aware be a RES

Post by johntalbott »

BLOMASKY wrote:
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.
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.
BLOMASKY wrote: 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.
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?
VocalDay Solutions - Agility - Predictability - Quality

We specialize in enabling business through the innovative use of technology.

AwareIM app with beautiful UI/UX - https://screencast-o-matic.com/watch/crfUrrVeB3t
RLJB
Posts: 914
Joined: Tue Jan 05, 2010 10:16 am
Location: Sydney, Australia

Re: V8.1 Feature Request

Post by RLJB »

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.
Rod. Aware 8.6 (latest build), Developer Edition, on OS Linux (Ubuntu) using GUI hosted on AWS EC2, MYSQL on AWS RDS
BenHayat
Posts: 2749
Joined: Thu Dec 23, 2010 5:48 am
Location: Fla, USA
Contact:

Re: V8.1 Feature Request

Post by BenHayat »

RLJB wrote:I'm probably being too simple here, but our clients ask us to...
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.
aware_support
Posts: 7523
Joined: Sun Apr 24, 2005 12:36 am
Contact:

Re: V8.1 Feature Request

Post by aware_support »

This topic has been somehow changed from the request to expose REST services to the request to consume 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.
Aware IM Support Team
johntalbott
Posts: 619
Joined: Wed Jun 17, 2015 11:16 pm
Location: Omaha, Nebraska
Contact:

Re: V8.1 Feature Request

Post by johntalbott »

aware_support wrote:This topic has been somehow changed from the request to expose REST services to the request to consume 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).
I encourage you to check out info regarding the OpenAPI Specification at http://swagger.io/specification/
VocalDay Solutions - Agility - Predictability - Quality

We specialize in enabling business through the innovative use of technology.

AwareIM app with beautiful UI/UX - https://screencast-o-matic.com/watch/crfUrrVeB3t
johntalbott
Posts: 619
Joined: Wed Jun 17, 2015 11:16 pm
Location: Omaha, Nebraska
Contact:

Re: V8.1 Feature Request

Post by johntalbott »

btw ... Swagger has a tool (desktop or online) that can generate the server or client REST API code in a variety of languages.

I wonder how easily the "client" Java code it produces could be "dropped in" as a jump start to create an AIM plug-in?
swagger.PNG
swagger.PNG (194.92 KiB) Viewed 32642 times
VocalDay Solutions - Agility - Predictability - Quality

We specialize in enabling business through the innovative use of technology.

AwareIM app with beautiful UI/UX - https://screencast-o-matic.com/watch/crfUrrVeB3t
BenHayat
Posts: 2749
Joined: Thu Dec 23, 2010 5:48 am
Location: Fla, USA
Contact:

Re: V8.1 Feature Request

Post by BenHayat »

aware_support wrote:This topic has been somehow changed from the request to expose REST services to the request to consume REST services. These are two completely different things.
The request is simply related to "exposing" Aware's resources as REST web service that can be used by any client and also is secured and uses authentication and authorization.
aware_support wrote: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.
This is a bit of unfair statement/request that you're asking us to do research and dig through Aware's system to find out what the limitations are and prove that current Aware's system is not complaint to RESET API standard. This needs to be investigated by Aware Team not your customers. Just saying "Exposing REST services IS SUPPORTED" has no value to substantiate the reality behind it and it a vague statement for us to prove otherwise, which is beyond the ability of the Aware's customers to do research for AwareSoft. It's Awaresoft responsibility to prove the product is up to date and conforms to open standard.
Just like I'm working on a project in .Net to use Vantiv Payment system. *I* have to prove to Vantiv (through certification process) that my code to make payment requests is PCI complaint. It's not Vantiv'd responsibility to prove to me that my code is not PCI compliant. Similarly, Awaresoft needs to prove that their REST service is up to standard and not customers prove to them otherwise.

Anytime a prospect had requested docs on Aware's REST system and I sent the very small pages of manual to them, they all had said, "This looks like the legacy RPC and is not up to standard and secure" and there is no real sample to prove that.
ACDC
Posts: 1138
Joined: Sat Jun 30, 2007 5:03 pm
Location: California, USA

Re: V8.1 Feature Request

Post by ACDC »

Ben,
When I look at the Service section in the configurator and the option to add a new service, it allows me to build something that lets me expose parts of my application in a REST-ful way

Are you saying this is not good enough or it's half-baked and does not cover everything? I have never used this before and have a project in the pipeline where I have made a commitment on the back of this feature and concerned I may not get there.
BenHayat
Posts: 2749
Joined: Thu Dec 23, 2010 5:48 am
Location: Fla, USA
Contact:

Re: V8.1 Feature Request

Post by BenHayat »

ACDC wrote:Ben,
Are you saying this is not good enough or it's half-baked and does not cover everything? I have never used this before and have a project in the pipeline where I have made a commitment on the back of this feature and concerned I may not get there.
In the past 3 years, when this subject had come up with new prospects (mostly insurance companies) and I had provided them Aware's document on the REST and installed the trial for them to see if it satisfies their need, the first thing they said, Aware's system does not provide full security and response with secure tokanized data. This means, we should be able to protect any part of the web service with Authentication & Authorization to secure data.

Secondly, the same client API calls that they had working with other backend systems that supported standard REST API, did not work with Aware. By this time, the prospect had already decided not to use Aware and I could not get more info from them.

The third point that was brought up, Aware as Web Service needs to run and respond in "Stateless" mode, so to allow them to have more than one server responding to client's requests, unlike when Aware runs as a full system in stateful mode.

What I'm asking Awaresoft, is to prove and show some sort of certification that their REST system complies with the Open REST system so we can show to our clients and be able to move forward. Currently there is very little docs, no sample and no proof that is fully compliant.

It's like, if I'm selling a product that does online Payment processing, I can't just claim it's PCI complaint as marketing scheme. I have to show that has passed PCI certification and my claim is legitimate. I can't ask my customers to go risk their business to prove to me that my Credit Card processing is not PCI compliant.
Post Reply