[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.

V8.1 Feature Request

ACDC

Support
I think it would be a great Idea for support to provide a sample REST interface in the Ordering example. We could then use Curl via the command line to experience the interface.

aware_support

Does this main that each resource exposed by the REST url must have the user login and password as part of the url

It is totally up to you how you implement this security. For example, you can implement your own tokens - generate a token, set its expiry date and then force users to call a REST API to get a token first and then force them to provide this token with every subsequent call. This will require quite a bit of configuration work, but it can be done (without even writing code).

BLOMASKY

Of course, if you have a Hammer, everything does look like a nail.

Since I am comfortable writing SQL and JavaScript and since, bottom line, any REST calls will end up doing CRUD against one or more SQL tables (without the plus of Aware Rules being triggered), and since I would have to write new processes to handle the "batch" processes that others will call via REST, I would use Node which supports OAuth and Email and etc. etc. etc. Realizing that when I have cascading rules (i.e. updating an order line, updates totals in order header. when that changes, the customer is updated, etc. etc.) I will have to write that logic.

Not arguing with anyone. I do see why peeps would like to use Aware for all of this, however, without OAuth, without an easy way to Test my Rest (damn, that rhymes) easily, I think I would find the Aware solution less than ideal.

Darn, I Missed Cinco de Mayo. Can I get a mulligan?

Bruce

johntalbott

So in conclusion ... we've learned that Bruce is not only crafty but also a poet. :lol:

BenHayat

johntalbott wrote
So in conclusion ... we've learned that Bruce [Lee] is not only crafty but also a poet. :lol:

And Martial Arts too. He made a few movies, like "Enter the Dragon". :mrgreen:

PointsWell

To circle back to the original post, given that the configurator will be a shiny new interface in v8, I'd really like to see a shiny new interface for managing the server side, more specifically consolidation of all of the .prop files into an interface that can provide some guidance (especially when running a remote non GUI server). From experience it seems like there is a ton of stuff that can be configured but I don't know what each element's options are, which makes fiddling a bit of a gamble.

BenHayat

PointsWell wrote
To circle back to the original post, given that the configurator will be a shiny new interface in v8, I'd really like to see a shiny new interface for managing the server side, more specifically consolidation of all of the .prop files into an interface that can provide some guidance (especially when running a remote non GUI server). From experience it seems like there is a ton of stuff that can be configured but I don't know what each element's options are, which makes fiddling a bit of a gamble.

1000+
I've asked for this feature several time, one central UI for all the configurations, than making changes to file (like the 80's), but no response was given.
In some ways, Aware feels like it was made for their internal use and then decided to sell some copies as well... 🙁

PointsWell

Hopefully this will be happening in v8.0 but if not for v8.1 please:

Can we have css overrides for all elements on the page. At the moment Separators require playing with Rendering overrides and what looked straightforward has proven to be not so...

MichaelQ

+100

bkonia

aware_support wrote
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.

While there may or may not be an "industry standard" for consuming REST services, there's no question that 99% of RESTful API's support JSON. Therefore, I suggest the AIM development team forget about trying to develop a solution that conforms to some REST standard and figure out the best way to load a JSON (or XML) object into AIM.

A JSON object consists of objects and arrays of objects. An AIM application also consists of objects and arrays of objects. Why not develop a parser that iterates through the JSON object and maps the data directly to a user-specified BO hierarchy? The user wouldn't necessarily need to recreate the entire JSON object, just the parts containing the data he needs. The parser would skip over any branches having no corresponding BO objects. The hierarchy could optionally consist of "Not Persistent" BO's. After loading the JSON into the BO hierarchy you could transform the data using the standard AIM functions and actions, then copy it into your permanent BO's

bkonia

As I mentioned to Vlad, my wishlist for REST consumption consists of the following items:

Choice of using GET or POST
If using POST, the ability to send a standard POST request or JSON.
Ability to specify custom headers in the request.
Receive the response in one of the following formats:
- Simple text value, which can be mapped to an attribute.
- String containing name/value pairs, which can be mapped to the attributes specified by the keys, in a single BO.
- JSON, mapped to a BO hierarchy, as described in my prior post.
- XML mapped to a BO hierarchy.

PointsWell

~~Added to wish list board~~ (Post Deleted)

ACDC

As I mentioned to Vlad, my wishlist for REST consumption consists of the following items:
Choice of using GET or POST
If using POST, the ability to send a standard POST request or JSON.
Ability to specify custom headers in the request.
Receive the response in one of the following formats:
    Simple text value, which can be mapped to an attribute.
    String containing name/value pairs, which can be mapped to the attributes specified by the keys, in a single BO.
    JSON, mapped to a BO hierarchy, as described in my prior post.
    XML mapped to a BO hierarchy.[/quote]
Sometimes, the only way to make a wish come true is to pay for it .
I would gladly commit to a custom plug-in of some sort that could bring this functionality forward

Are there any other volunteers and someone who can write the spec and submit to support for a quote on getting this done

bkonia

Actually, Vlad has informed me that this is on the roadmap for 8.1. I'm not sure if they intend to do the complete feature set I listed here, but at least some of this functionality should be implemented.

tford

Brad,

Do you know if the functionality described above which you say should be in 8.1 would theoretically have the ability to receive Webhooks from SendGrid or Mandrill as described here:

SendGrid: https://sendgrid.com/docs/API_Reference/Webhooks/index.html
Mandrill: https://mandrill.zendesk.com/hc/en-us/articles/205583217-Introduction-to-Webhooks

The also would impact Ben's request at: Using "SendGrid" SMTP, Best choice in AwareIM?

That would be HUGE if 8.1 would make webhooks configurable in the Configuration Tool. It would substantially extend the email functionality to include great info about how & when a recipient interacts with an email sent by AwareIM. When paired with additional AwareIM processing rules, a user could trigger other workflow steps based on the webhook info received.

BenHayat

tford wrote
Brad,

Do you know if the functionality described above which you say should be in 8.1 would theoretically have the ability to receive Webhooks from SendGrid or Mandrill as described here:

SendGrid: https://sendgrid.com/docs/API_Reference/Webhooks/index.html
Mandrill: https://mandrill.zendesk.com/hc/en-us/articles/205583217-Introduction-to-Webhooks

The also would impact Ben's request at: https://www.awareim.com/forum/d/9731>

That would be HUGE if 8.1 would make webhooks configurable in the Configuration Tool. It would substantially extend the email functionality to include great info about how & when a recipient interacts with an email sent by AwareIM. When paired with additional AwareIM processing rules, a user could trigger other workflow steps based on the webhook info received.

Exactly Tom. Having REST communications, allows us to communicate with mail server in two way fashion, so we know if mail was delivered or not and etc. The SMTP route, you have no way to know and in critical situations where email delivery is critical.

johntalbott

Ain't no REST for the wicked.

bkonia

Do you know if the functionality described above which you say should be in 8.1 would theoretically have the ability to receive Webhooks from SendGrid or Mandrill as described here:

Hi Tom,

I reviewed the Sendgrid and Mandrill docs. Most of this functionality is already supported by the AIM REST service. The problem is, the REST service only supports GET requests, not POST requests and these web hooks require POST, more specifically JSON POST. The main difference between GET and POST is with a GET, the entire request is encoded within the URL parameters. With a POST, it's encoded within the request body, which allows for sending a lot more data.

It would be simple for the AIM development team to add support for POST and JSON POST requests in the REST service. The POST parameters or the JSON object would be mapped to attributes in exactly the same way as the GET parameters. When creating a REST service, the developer would specify whether he wants the service to receive the data in GET, POST or JSON POST format. Hopefully, if enough people chime in, they'll be encouraged to implement this.

RLJB

I think Brad has described a perfect method in his last forum post on Page 2, consuming a restful API in such a manner would be great.

ACDC

not POST requests and these web hooks require POST,

If you set up the Sendgrid POST webhook event to use your URL configured as follows:

"http://localhost:8080/logonOp.awsp?domain=YourBusinessSpace&userName=admin&password=password&ProcessName=YourProcessName&ObjectName=YourObjectName&InitParam1=Value1&Param2=Value2&Param3=Value3...etc etc"

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

« Previous Page Next Page »