...

Jaymer

Sounds great.
You missed the Headless Aware presentation by Himanshu at last years conference.
I think you'd be interested in the direction that was going - my only issue with it was it took massive amounts of time (relatively speaking) to do the client-side programming (data was being retrieved via rest w/aware). Himanshu also has the luxury of having ace Java developers to do anything he needs w.r.t. handshaking/communication.

Maybe a nice lucrative direction for Vlad, instead of doing the visual "draw links between BOs to create references" new feature - MS Access had that 15+ years ago. Has anyone NOT purchased aware because it didn't visually connect tables? There's plenty other reasons why Corporate isn't going to adopt Aware and its not cause of that (talk to Ben & Talbot).

I know Vlad thinks he needs to keep stuff simple for the non-tech users, but something like an awesome Aware REST service would bring in far more revenue & users than are going to adopt because Aware is still "for the non-techies"... cause, as people have posted on the forum, they bought into the Aware is for non-techies and then realized they still needed to dig under the hood a bit.

true, the Tom Fords et. al. have resisted using external tools to get the job done (stored procs, node.JS, etc.).

PointsWell

Jaymer wrote
I know Vlad thinks he needs to keep stuff simple for the non-tech users

If the product USP is simplicity of development then keeping stuff simple is the corporate strategy not an opinion.

The product is marketed on the basis of low-code in the vein of OutSystems and Mendix. Visual programming as a concept has been looked down upon for too long as being lesser than hand crafting. The world is now too complex for that to continue.

ACDC

Maybe a nice lucrative direction for Vlad, instead of doing the visual "draw links between BOs to create references" new feature - MS Access had that 15+ years ago.

I agree, I don't see myself ever using this feature, when I get down to design an app the design plays out in my head with me driving the configuration tool as it is. Having a fancy graphical GUI to drag a drop and create relationships is just "bling" , which is probably planned because other low code competitors have it .

Not only it opens Aware to a huge market, but we can also now build true native code in Flutter and use it with Aware back end.

Imagine that - this has been an educating read, thanks Ben. Its functionality like this that will drive adoption and let Aware developers leverage the move by corporates to low code development environments and compete head-on with some of the other well known low code players gaining traction in the corporate space

tford

true, the Tom Fords et. al. have resisted using external tools to get the job done (stored procs, node.JS, etc.).

This is somewhat true, but I don't really understand the relevance to this thread. Enlighten me.

BLOMASKY

Every app has 3 parts. The UI, The business logic and the data maintenance (from here on called the DB).

2 parts are easy to discuss,

1st, the UI will run on the client, and if Aware is being used as a REST server, then flutter or some other language will handle the UI. So lets ignore that for now.

2nd, the DB which is performing CRUD against a SQL database. Since you would have to write FIND, UPDATE and CREATE in Aware since the UI is being handled outside of aware. I believe it is not any more efficient to write these vs. CREATE, INSERT or UPDATES in SQL and in many cases much lower performance, since aware only works with one record at a time when updating / creating records. (for example, I have a quoting system, where when the user wants to convert a quote to an order, each quote can have up to 20 line items and aware will call 20 insert statements, instead of 1 if written in SQL)

Now, we get to the fun part. The business logic. Some should be handled on the client, i.e. if you have to enter a persons SEX and don't enter M or F, you might want an immediate response informing the user of the invalid input. Pretty sure that would be much slower if you had to communicate back to the aware server each time the user changed the input.

Where Aware does have an advantage is the rules that can be triggered with (IF BO.attr WAS CHANGED or IF BO is new). This can be the huge savings in code that Ben mentioned, Not having to write a trigger or call a procedure each time records are added or attributes are changed.

Because of this narrow focus, I think this would be a very difficult sale. I could be wrong, I am usually wrong, but since there are about a gazillion people who can write stored procedures, triggers in their sleep and with the lack of Aware talent, this might be tough to sell to corporations.

I think what aware brings to the table is the speed of development, speed of maintenance, ease of maintenance when using Aware for the entire application and, when necessary call other REST systems for functionality that aware does not have built in.

Just my 0.02 cents worth.

Bruce

aware_support

Just to clarify - Aware IM already supports REST services. Nothing stops you from writing native client applications in whatever language you like and use Aware IM REST as the backend (in fact, some people have done that and demo'ed at the Conference in Providence). The ONLY thing that is missing at the moment is security (full OAuth support for services exposed through REST).

If my understanding is correct (and I could be wrong) you would only need to worry about security if your services are accessed by a third-party. If, however, you are writing client applications that use REST as a back-end, why would you worry about security - why would you ask for a token for yourself??

Now, if your services ARE accessed by a third party, then you may want to support proper security. Or not. Depends on the nature of the application. And to us at the moment it is not quite clear how many applications would require full OAUth security for 3rd parties to access their services.

Incidentally, we ARE researching this as we speak - we performed an investigation of how much work would be required to support OAuth for services exposed by Aware IM for the next version. And it looks like it's quite a lot of work. So before we embark on this project we need to understand full benefits of this feature. So far, it looks 50/50 at best.
Your comments on this are very welcome. Maybe I will create a separate thread where people can vote...

PointsWell

ACDC wrote
I get down to design an app the design plays out in my head with me driving the configuration tool as it is. Having a fancy graphical GUI to drag a drop and create relationships is just "bling" , which is probably planned because other low code competitors have it .

While this is all well and good to design in your head, it makes it very much harder for maintenance by another person. I have come back to my code that I have been working on intensively for a number of years and still have moments of "What does that do".

Drawing ERD from Aware is of minimal use, but being able to produce a flow based process map would be incredibly valuable to me.

aware_support

In today's wild wild west, security is THE MOST important, no matter who is using the service. Hackers are all over the places and you are asking

This is just a blanket statement. Why on earth would you want OAuth protocol to use your OWN services??? Are you going to grant an access token to yourself?? This just doesn't make any sense.

And security is NOT always necessary - it depends on what you are doing.

Jaymer

FWIW,
here's a Node.js OAuth2.0 server implementation

This would allow Bruce, for example, to expose his client's POs, Ordering, etc. to their customers and vendors.
He would use JS to code, parse, etc. all the requests and post directly to the database (which bypasses any Aware business rules).

Question: If Aware DID NOT have this [security] built into it, what chance would Aware have of being the solution for his client?
or... if Aware doesn't offer the highest level of REST security, they'll do it in another tool.
So, if we [ie. Vlad and team] don't do this now, then how many more future opportunities will be missed by us [developers] and Aware?

(cross posted to the REST Vote thread - unsure where the best place for this is)

aware_support

And this is what we will most likely use if the project goes ahead (Apache CXF):

http://cxf.apache.org/docs/jax-rs-oauth2.html#JAX-RSOAuth2-Introduction

BLOMASKY

BenHayat wrote
BLOMASKY wrote
Where Aware does have an advantage is the rules that can be triggered with (IF BO.attr WAS CHANGED or IF BO is new). This can be the huge savings in code that Ben mentioned, Not having to write a trigger or call a procedure each time records are added or attributes are changed.

Because of this narrow focus, I think this would be a very difficult sale. I could be wrong, I am usually wrong, but since there are about a gazillion people who can write stored procedures, triggers in their sleep and with the lack of Aware talent, this might be tough to sell to corporations.

I think what aware brings to the table is the speed of development, speed of maintenance, ease of maintenance when using Aware for the entire application and, when necessary call other REST systems for functionality that aware does not have built in.

Just my 0.02 cents worth.

Bruce [Lee]

The RED section, you are making an assumption that is far from the truth.
You're saying anyone writing client code, has access directly to the Db without an HTTP server (like Aware) as the the middle tier.
Aware as a REST service does T H R E E major things,
1) a complete HTTP Request/Respond system
2) a Complete ORM middle tier between client and DB
3) Last but not least, Aware's Process and rule engine allows us to build sophisticated routines against GET, POST, PUT and DELETE verbs.

We can do all the three above in Node.js, .Net Web API or Java, But aware will save you building the infrastructure, all the data plumbing, Data Context management, Data structure and much more.

What we need is to make sure Aware is up to par with today's REST standards and it is fully secure. The rest is already there.

Perhaps you mis-understood me. I was not saying that anyone writing client code is a DB or has access to a DB, What I am saying is that when your offering Aware as the middleware to a corporation, Your offer is "You don't have to know SQL, you just have to learn Aware" With the limited # of Aware programmers, they would have to commit to training the talent. If they decide to go with Node, for instance, then they will certainly need SQL developers (of which there are many). you said:

Aware as a REST service does T H R E E major things,
1) a complete HTTP Request/Respond system
2) a Complete ORM middle tier between client and DB
3) Last but not least, Aware's Process and rule engine allows us to build sophisticated routines against GET, POST, PUT and DELETE verbs.
the 1st 2 can be accomlished by Node with Express in about 20 lines of code. Yes, we do agree on the 3rd. Aware does provide a robust rules based backend that other tools do not. However, I feel that if you decouple the front end from that, you loose so much functionality. That is why most of the competing low-code solutions, provide all 3 layers in 1 tool. UI, MiddleWare and DB support.

Bruce

aware_support

Support claims that it already does, but I can't find any docs to show how to go about it and program it accordingly.

All you need to is export REST services in your business space. This is well-documented and there is also a tutorial on how to do this. The rest is just making an HTTP call to to a specific URL from the front-end of your choice. The HTTP call will activate the service.

Jaymer

W.R.T. Documentation

Well, there is a tony section in the User Guide that says exactly whats in the video.
Either of those will help you get the format for a REST URL to publish some of your own Aware data.
This is VERY easy.

BUT, there's not one hint of how to use a parameter.
Sure, I can put it on my URL
.../REST/mytestbsv/offices?lic=00818176

but there's no mention or idea anywhere how to use that passed in parm to lookup JUST that office specified ("00818176")
Without a parm, my REST service would use the process "All_Offices" to respond to this:
.../REST/mytestbsv/offices ..... (this works fine)

That process has 1 rule: FIND ALL Office
How am I supposed to modify this FIND to incorporate the requested parm?

I guess once I have this info, I might be able to do a POST? and update data?
or is that not supported?

Jaymer

yes, i realize that.
i'm using Postman.
Aware seems oblivious to any parm data coming in, AND
does not seem to do anything different if I do a GET or POST.
How am I supposed to get to that "request body" info?

I don't see any indicators in either Server or Tomcat window, or in Logging.

AND, I notice that it just sends back all attributes for my BO.
This is where you, in a post a while back, said you need to make another View (or something) of the BO and only have the attributes in the BO that you want to make available to the Service.
How am I supposed to do that here - I need to go to SQL Server and make a View? What if I don't want to involve a DBA to make changes to the database? Is there no way inside Aware to limit the columns that are exposed?

aware_support

BUT, there's not one hint of how to use a parameter.

This is from the How To Guide:
"The default URL where Aware IM will listen to REST-ful requests has the following format:
http://ServerName:ServerPort/AwareIM/REST/BusinessSpace/ServiceName?parameters"

I guess, the document should be clearer on this, but it is quite obvious. Parameters are specified as paramName1=paramValue1&paramName2=paramValue2&...

Where paramName1, paramName2 etc are names of the attributes of a business object that is specified as input to the process implementing the service.

For POST requests these parameters must be in the body of the request.

craigd

Jaymer wrote
W.R.T. Documentation

BUT, there's not one hint of how to use a parameter.
Sure, I can put it on my URL
.../REST/mytestbsv/offices?lic=00818176

It's just like the other incoming services. Add a reference to a BO and then that BO is created when the REST request is received. For example, I have a service that sends out an approval request email with email body containing the REST URL (like url../task_response?taskId=######&taskResponse=####) to approve the task. AwareIM receives that REST request, parses the URL parameters, finds the correct task from the taskID and then approves/rejects based on the other parameters.
The actual ID is a random UUID that is generated when the task IS NEW, prior to sending out the approval notice.

Jaymer

aware_support wrote
I guess, the document should be clearer on this, but it is quite obvious. Parameters are specified as paramName1=paramValue1&paramName2=paramValue2&...

This doesn't need to "be obvious"... because
its clearly defined in BOTH the video and manual.

But thats not what I asked... "How to specify a parm", I wrote:

Sure, I can put it on my URL
.../REST/mytestbsv/offices?lic=00818176

but there's no mention or idea anywhere how to use that passed in parm to lookup JUST that office specified ("00818176")

Let me try again.
Here is my REST URL #1:
https://myurl.com/AA/REST/s1/offices
The "offices" service is tied to a process "all_offices" which is "FIND ALL OFFICE"
So, when I run it, I get a reply page back with a bunch of offices listed, showing all the attributes from OFFICE.
THIS IS EASY.

My 1st Question Mark in my post was:
How am I supposed to modify this FIND to incorporate the requested parm?

I do not understand HOW A URL PARAMETER gets "into" aware and how its referenced in aware.

Using THIS URL:
https://myurl.com/AA/REST/mytestbsv/offices?lic=00818176
-> I'm still using the "offices" service
-> The service still has the same process defined to implement the service.
-> The process uses FIND ALL OFFICE, so how is that supposed to use the passed in parm "00818176"?

This is in NO WAY obvious, or documented, or shown in any example, printed or video.

PointsWell

Jaymer wrote
Using THIS URL:
https://myurl.com/AA/REST/mytestbsv/offices?lic=00818176
-> I'm still using the "offices" service
-> The service still has the same process defined to implement the service.
-> The process uses FIND ALL OFFICE, so how is that supposed to use the passed in parm "00818176"?

This is in NO WAY obvious, or documented, or shown in any example, printed or video.

That seems like a completely different service.

If you consider a query within AIM (ignoring the rest side) if you want to find OFFICE=xyz then that query is different from FIND ALL OFFICE.

Jaymer

BenHayat wrote
I think I said "ViewModel or DTO", NOT an SQL View.
A DTO or ViewModel is a temporary BO Model you create in order to get data from client or send data. This is critical, because during POST (from client), you want to examine all the data BEFORE you put it into BO and during a GET call by client, you ONLY want to send a subset or even a flatted (two BOs combined as a new temp model) to Client.

YES, DTO is what I remember.
After reading that, I created a physical SQL table (maybe a view, but I don't think so).

But w.r.t. THIS discussion, and only a GET, how are you supposed to do this in Aware?
Create a NP BO (based on incoming parms), and write data into it, before it gets sent out? (seems like extra work)
Without a way to specify attributes to return to the REST caller, this seems like a major shortcoming.

Jaymer

craigd wrote
It's just like the other incoming services. Add a reference to a BO and then that BO is created when the REST request is received. For example, I have a service that sends out an approval request email with email body containing the REST URL (like url../task_response?taskId=######&taskResponse=####) to approve the task. AwareIM receives that REST request, parses the URL parameters, finds the correct task from the taskID and then approves/rejects based on the other parameters.
The actual ID is a random UUID that is generated when the task IS NEW, prior to sending out the approval notice.

1) OK, you'd have to assume by now I know nothing of "other incoming services".
Where is this documented?

2) I've sent plenty of links via emails, but not to just send a yes/no response back into Aware. Usually to log in and see or enter data. This is a great idea you have, because one of the things brought up in another thread was the overhead created by the logging in, and that context hanging around (and using resources) until it timed out.

3) HOWEVER, your use, great as it is, still didn't answer for me how your process "parses the URL parameters", which is my main issue right now.