Some of you are happy with Aware as a RAD tool inside your company, and others are happy with a few customers to do custom apps.
This discussion is for those who seek to "make millions" on one or several SaaS apps written in Aware.
I've had a discussion with 3 AIM peers in the past 10 days - all of whom have some degree/concern over just how to accomplish this feat in Aware.

First let me say that i'm very happy with the level of response I've seen from Vlad and the development team over the past few years of my involvement in Aware. I see things in the product (even in the latest build) that are wonky or immature or may even be a bug - but I attribute that to only being at that state because it hasn't been pushed/prodded or brought to the forefront enough for Vlad to fix it yet. So I'm not hung up over small stuff like that because we know stuff gets fixed when it rises to the top of the hitlist.

So, back to SaaS.

ISSUE # 1 - CO-MINGLING OF DATA

The two prevailing AwareIM strategies (from what I've seen) are using code to separate customer data (ie. a TenantID in data rows) to give a user only access to data that is for/from his tenant ID. The other being to use READ PROTECT to allow Aware to "filter" the data.
Nevertheless, the data IS CO-MINGLED in one database, which can be an issue in the medical world or just if your customer is hesitant to have his data out on the cloud mixed with other people's data. So, for the sake of discussion in this thread, lets say this strategy is not acceptable for the future, EITHER because we are in a medical situation (requiring non-mingled data) or the market/customers dictate it.

ISSUE # 2 - Separate BSV and Database per Tenant = NO CO-MINGLING OF DATA

Mark Bailey told me the other day he doesn't do his original model of SaaS anymore (which is the TenantID in the data) and now he has each customer (in this particular Saas app that we were discussing) with their OWN BSV and their own Database. He uses Aware's Upload New BSV function (under the standard menu) to upgrade and Aware handles all the table mods if needed. Very simple - but he's only at 4 customers. And not likely to go to 1000, so for now its a manageable deal. But what if you create a SaaS that gets traction, is cheaply priced and 100 sign up per month? So, likewise, lets discount this for those real go-getters who want to make a million and can't do it with 5-20 Tenants, and see a big future ahead! (Bruce, btw, wants you to know that if you're signing up 100 customers a month, you can hire him to copy your BSVs for you 🙂 )

ISSUE # 3 - How to automatically provision a new Tenant with SubDomain

A) Robin showed some of this at the recent conference. While I haven't seen it, one issue revolved around creation of a Tomcat subdomain. Lets say you come to my app and sign up for 30-day trial with code/company/domain/instance name "jaymer". The screen tells you "Access your new system at http://jaymer.coolSaasApp.com ". You can modify Tomcat's server.xml file to allow for a subdomain. Robin was saying that Tomcat has to restarted for this to be recognized - but more research needs to be done. See https://tomcat.apache.org/tomcat-8.0-doc/config/host.html#Automatic_Application_Deployment and https://tomcat.apache.org/tomcat-8.0-doc/config/context.html

B) Another issue is how to automatically get a new BSV into the system once a customer signs up. I'm not sure how Robin was doing this, but he also said something needed to be restarted in order for Aware to see the new BSV.
I think, that since the BSV is stored inside 1 ROW in the database (table BAS_DOMAINS and DOMAINVERSIONS) it should be possible to have a Stored Procedure CREATE A NEW BSV simply by creating a new row in these tables and VOILA! the new system is online. After copying, it needs to be modified to [at least] point to the new database - not sure how to do that. The user templates & documents are stored in other tables so those have to be copied too.
Maybe enough interest could prompt Vlad to make an API which could easily make this happen since he has code to do all this already. Like I said in the intro, things just have to have enough priority to make them get done.

In any case, this Provisioning is something that an Aware Developer would want to happen with minimal effort if not completely remove developer-involvement when setting up a new customer.

ISSUE # 4 - BASID_GEN

There have been grumblings about this (probably forever) but certainly recently about the way Aware generates its ID #s for table rows. And some improvement is coming in 8.3 - I'm not quite sure what that is... perhaps someone can comment below.
OK, your BAS_IDGEN table is used for your entire installation of Aware on a licensed server. One license. One IDGEN. One batch of ID #s system wide on that server of 1 thru 2 Billion. NO matter how many Tenants or BSVs or databases you have on that server. Whichever above SaaS strategy you might use, you have this limit.

THIS issue is the fact that Aware's ID #s are (in MS SQL) an "int" datatype, which puts them at a maximum value of approx 2,000,000,000 (2 billion).
But, not only is the limit an issue (maybe a minor one), the other is that all data rows in the system have their ID #s scattered all over the place with gaps in them. Those ID #s ARE IN FACT the Primary Key of tables. And some IT Managers may have issues that the values are not consecutive and have large gaps (caused by other used on that server creating data which use the IDGEN numbers). Dunno. (Neither of these are particularly troubling to me.)

Robin has an issue with this because of a known real-world case where this affected a SaaS company and the integer datatype bothers him.

ISSUE # 5 - SINGLE BSV with Connection String

One item that has hit the forum in the past year is that of dynamically connecting to different databases. Aware doesn't use a traditional CONNECTION STRING that goes back to early Windows/Access & ODBC days. I'm not sure how this architecture would fit into Aware's world or if it even could.
Since Aware already manages server-wide tables (BAS_IDGEN for one), why not manage a BAS_CONNECTIONS table. Could you log into a BSV (which validates the default REGULARUSER table) and THEN determine a Connection String to point to data? A BSV could "own" many CSs so on the fly you could switch to other data. Yes, talking too much on this will make your head explode. Would Aware's unique and very-valuable table/data/scheme Synchronization still be able to function? One CS endpoint has data in sync with the current BSV and what about the other CSs that are now out of sync. How to keep all that straight? It boggles my mind every time many changes have been done in Testing that Vlad 99.995% of the time perfectly converts the Production database when you Publish.

IN SUMMARY
If we discount Issue # 1 with traditional TenantID in Data, then is Issue # 2 an issue? I think it is for those with many many potential Tenants.
Will Issue 3 become easily doable with no intervention? Is this the ideal solution?
Does the IDGEN Integer limit bother anyone? and/or does support already have a plan?
Is a connection string too much of a pipe dream?

OK, well enough for now. Please post your SaaS concerns and ideas and lets see what replies we can get from SUPPORT.
thx
jaymer...

NOTES:
N1) Splitting off to another server incurs another $100/mo (lets say) PLUS another Aware license (approx $100/mo amortized across 3 years). Assume you made that new server because you needed to put 10 customers on there and you're only at $20/customer/month to pay for the server and license. If you're charging $250 per month for SaaS then you're fine, if its $49 then you're gonna have to hope you can put more than 10 customers on that server.