If you have questions or if you want to share your opinion about Aware IM post your message on this forum
#43396 by aware_support
Thu May 04, 2017 9:52 pm
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.
#43397 by BenHayat
Thu May 04, 2017 11:14 pm
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.


Much appreciated for the clear answer.
#43399 by ACDC
Fri May 05, 2017 8:08 am
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.


Does this main that each resource exposed by the REST url must have the user login and password as part of the url
#43400 by BLOMASKY
Fri May 05, 2017 9:31 pm
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?


Good Question!
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
#43404 by johntalbott
Sat May 06, 2017 4:30 am
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 ... :)
#43407 by ACDC
Sat May 06, 2017 9:52 am
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.
#43413 by aware_support
Mon May 08, 2017 12:37 am
Code: Select allDoes 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).
#43423 by BLOMASKY
Mon May 08, 2017 6:04 pm
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
#43426 by johntalbott
Tue May 09, 2017 12:43 am
So in conclusion ... we've learned that Bruce is not only crafty but also a poet. :lol:
#43429 by BenHayat
Tue May 09, 2017 10:40 am
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:
#43586 by PointsWell
Tue May 30, 2017 1:37 am
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.
#43587 by BenHayat
Tue May 30, 2017 1:48 am
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... :(
#43750 by PointsWell
Thu Jun 22, 2017 7:43 am
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...
#43808 by bkonia
Tue Jul 04, 2017 9:03 am
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

Who is online

Users browsing this forum: MSN [Bot] and 24 guests