So it all basically boils down to PCI compliance and OAuth support (token authorization).
This is true - Aware IM does not support them, so if you need high security for your REST services you need to build something on top of what Aware IM offers yourself (by getting your hand dirty and writing code).
What Aware IM offers is REST services that can be used when there are no high security requirements involved. If you want to implement some security (that doesn't conform to PCI and OAuth standards) then you can easily do it yourself in your application.
PCI and OAuth are way too complex for 8.1 and I am not even sure they can be supported at all within the realm of a generic application builder that Aware IM is. Some investigation here may be required, but it depends on how high a demand is for this support.
V8.1 Feature Request
-
- Posts: 7526
- Joined: Sun Apr 24, 2005 12:36 am
- Contact:
Re: V8.1 Feature Request
Aware IM Support Team
Re: V8.1 Feature Request
Much appreciated for the clear answer.aware_support wrote: PCI and OAuth are way too complex for 8.1 and I am not even sure they can be supported at all within the realm of a generic application builder that Aware IM is. Some investigation here may be required, but it depends on how high a demand is for this support.
Re: V8.1 Feature Request
Does this main that each resource exposed by the REST url must have the user login and password as part of the urlIf you want to implement some security (that doesn't conform to PCI and OAuth standards) then you can easily do it yourself in your application.
Re: Educate me pls for the rational of having Aware be a RES
Good Question!johntalbott wrote:BLOMASKY wrote:
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?
1st, to answer your question, I have node modules to send email, However, lets talk about your simple example "a business partner that wants to place an order in your AIM system directly from their system via REST". Now, my order entry stystem starts with selecting a Customer (ok, the business partner should know that, then I create an OrderHeader BO which has some lookup tables, (i.e. Ship via, Terms, etc.) Entering the OrderHeader is done with a form, and information is validated with rules, that will Report Error if any data is invalid (i.e. over credit limit).
Then the user entered one or more OrderLine BO Records. They have a Pick List to select the inventory item (again, with validation so they cant sell more than we have in stock, etc. etc.).
How do you propose to handle this via REST without the AwareUI? Thats what has me so confused. I don't think you could have a "CreateOrderHeader" REST Call and a "CreateOrderLines" REST call, since there is potential UI during them.
Color me confused.
Bruce
-
- Posts: 619
- Joined: Wed Jun 17, 2015 11:16 pm
- Location: Omaha, Nebraska
- Contact:
Re: V8.1 Feature Request
REST services are "headless", meaning in our example the AIM UI never comes into play.
The business partner (BP) peeps are using their own system with it's own UI, back end services, etc. It's has it's own order entry UI. Let's say the user picks the category of Lumber .. as a result ...
1. A call is made from BP system UI back to the BP services layer
2. The BP service layer recognizes Lumber was selected and calls the Lumber company's REST services to retrieve a list of lumber products and send the list back in a response back to the BP service layer.
3. In turn the BP service layer pushes the response back to the BP UI to be displayed.
Continuing on ... when the order is all put together in the BP system and is submitted ... the BP service layer recognizes the order includes lumber .. so to fulfill the order it submits the lumber related order data to the lumber company's REST service.
Maybe their order also includes windows, so the BP service layer also pushes the window related order data to a REST service exposed by their window supplier to be fulfilled.
That's the idea anyway ...
Happy Cinco de Mayo amigo ...
The business partner (BP) peeps are using their own system with it's own UI, back end services, etc. It's has it's own order entry UI. Let's say the user picks the category of Lumber .. as a result ...
1. A call is made from BP system UI back to the BP services layer
2. The BP service layer recognizes Lumber was selected and calls the Lumber company's REST services to retrieve a list of lumber products and send the list back in a response back to the BP service layer.
3. In turn the BP service layer pushes the response back to the BP UI to be displayed.
Continuing on ... when the order is all put together in the BP system and is submitted ... the BP service layer recognizes the order includes lumber .. so to fulfill the order it submits the lumber related order data to the lumber company's REST service.
Maybe their order also includes windows, so the BP service layer also pushes the window related order data to a REST service exposed by their window supplier to be fulfilled.
That's the idea anyway ...
Happy Cinco de Mayo amigo ...
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
We specialize in enabling business through the innovative use of technology.
AwareIM app with beautiful UI/UX - https://screencast-o-matic.com/watch/crfUrrVeB3t
Re: V8.1 Feature Request
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.
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.
-
- Posts: 7526
- Joined: Sun Apr 24, 2005 12:36 am
- Contact:
Re: V8.1 Feature Request
Code: Select all
Does this main that each resource exposed by the REST url must have the user login and password as part of the url
Aware IM Support Team
Re: V8.1 Feature Request
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
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
-
- Posts: 619
- Joined: Wed Jun 17, 2015 11:16 pm
- Location: Omaha, Nebraska
- Contact:
Re: V8.1 Feature Request
So in conclusion ... we've learned that Bruce is not only crafty but also a poet.
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
We specialize in enabling business through the innovative use of technology.
AwareIM app with beautiful UI/UX - https://screencast-o-matic.com/watch/crfUrrVeB3t
Re: V8.1 Feature Request
And Martial Arts too. He made a few movies, like "Enter the Dragon".johntalbott wrote:So in conclusion ... we've learned that Bruce [Lee] is not only crafty but also a poet.
-
- Posts: 1460
- Joined: Tue Jan 24, 2017 5:51 am
- Location: 'Stralya
Re: V8.1 Feature Request
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.
Re: V8.1 Feature Request
1000+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.
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...
-
- Posts: 1460
- Joined: Tue Jan 24, 2017 5:51 am
- Location: 'Stralya
Re: V8.1 Feature Request
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...
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...
Re: V8.1 Feature Request
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.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.
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