I have questions, maybe someone from the forum visitors will share their knowledge or give their recommendations.
Is there documentation or at least a clear direction so that Moqui can be installed on the server and configured as a SaaS.
The purpose of SaaS is to use one copy of Moqui on one server, but at the same time give separate access for different companies in the ERP. For example, I will install on the same ERP server with a domain: https://moqui-good-erp.com (this is an example) → a visitor comes in and registers a new account in the system for his company (let’s call the company “Good Test Company” as an example) → for his company “Good Test Company” this visitor (you can say as the administrator of “Good Test Company”) adds new users/employees (assume 10 accounts) = all these 10 accounts are linked to the company “Good Test Company”.
But in order not to install several copies of ERP on one server, I would like to just set up the system as SaaS.
Where to begin?
I have a system installed on the CRM framework server.
I want to integrate ERP with CRM. But, the problem is that simply using the API will not work, since it will not be possible to achieve the goal.
Purpose: to combine my CRM and ERP with installation on one server, to create one database for user authorization on two systems at the same time, so that users do not have to log in to each system separately and so that I do not have to install copies of the system on one server.
The problem here is to separate the companies, a lot of entities already have an ownerPartyId which you could use, however every request to the system should be checked that only data is accessed which is assigned to the ownerPartyId. Further you need to separate the Ledgers which is also possible in moqui, i explained that in an earlier posting.
This access checking i implemented in all REST endpoints used by a Flutter frontend client which is a more simple interface than the one used in Moqui.
Have you ever done, or tried anything like this before? If not, then I’d recommend doing a lot of research and proof-of-concept development before even considering it.
Can you create a SaaS application with Moqui, with limited functionality in an application designed for this purpose? Yes, and it’s not too difficult (the multi-organization functionality, built on top of configurable record filtering that is a feature of the Entity Facade and the Artifact Authorization side of security in Moqui). One example of this can be seen at:
If you want full multi-tenant with all functionality in Moqui, then you have some serious technical issues to solve. It is one thing to add a “tenantId” column to every table in the database (can add some quick code in the Entity Facade’s database metadata management functionality to do this easily), and to force a tenantId added to each query based on a value in each session based on however you’re going to handle per-tenant login, but it is another to have all access control, logic, and data access completely isolated between tenants.
Have you noticed that platforms that are fully multi-tenant tend to have their own custom scripting (and even templating) languages instead of using something general like Groovy? This is because secure tenant isolation requires 100% secure code isolation. This is not an easy problem to solve. It is possible, but it isn’t a small thing, even the testing required to ensure this may be larger than your budget based on what you’ve described.
Another big issue is data access. If you want to allow data exports or any interaction with the database you’ll need to build layers around the shared database that completely isolate tenant data. For example: If you want to allow any custom reporting, the reporting tool must go through an interface that enforces the tenant isolation.
In general, Moqui is not designed for multi-tenant SaaS applications. As I mentioned above, it is very possible to build limited scope SaaS application using Moqui and the record level authorization based filtering, but the OOTB applications are designed for multi-organization with partially shared data, not for complete isolation. The System and Tools apps would be incredibly difficult to make available with full logic and data isolation between tenants.
If you want to offer applications that can’t be customized or extended except by the organization running it or highly trusted third parties, then you could do that. If you aren’t careful about every aspect of the system you build this is a highly problematic and expensive domain to get into. Can it be done? Yes, but it would require a lot of time and effort to do securely! That was true for SalesForce, both their early applications and stepped up a bunch for their force.com SaaS application platform, and it is true for every other massively multi-tenant SaaS application out there.
The primary goal of Moqui is to be highly extendable and customizable, and scalable down to companies with 10-20 people and up to companies with thousands of people (or maybe tens of thousands with a bit of effort, depending on the functional scope involved). It can be used by smaller companies, even 1 person companies like mine, but that would be for people who are really into it and don’t mind a little hosting expense or prefer to host it on their own hardware (which is what I do).
What I’ve recommended to others who are serious about this path is to start with container-based hosting. There is almost zero risk of breach of tenant isolation, and the cost per container is pretty small (and it is easy to have multiple databases on one database server, and Moqui supports a forced prefix for Elastic/OpenSearch index names to run multiple tenants on a single ES/OS cluster). There are many tools out there to help manage this sort of thing, and if you want to manage in custom ways the Multi-Instance management functionality in Moqui is a good place to start.
Once you get to 100 instances and are confident to you will have at least 1,000 or preferably 10,000 instances then start considering single-database multi-tenancy. I don’t know what the number of instances is where it will be cheaper overall to user a single-database massively multi-tenant architecture versus a containerized multi-instance architecture, but I’d guess the number is closer to 10,000 instances than 1,000. The companies using Moqui for SaaS products to date generally have more complex high-ticket software, so the highest number of instances I’m aware of is in the hundreds.
I’ve had many discussions and even done some proof of concept work related to this. As I said above, if you have very limited functionality exposed to end users then it isn’t too hard. If you want large applications where users can do some of their own administration, reporting, etc then you start running into big problems. Eventually you find that you have to build something like Force.com with a full tool stack, data and logic and integrations and UI and on and on, that securely isolates tenants. This isn’t easy.
As a very rough estimate: I wouldn’t try this without a 7-figure budget unless you are dramatically limiting the functionality exposed to users (like the Coarchy example, a limited scope SaaS application offered by a company that does all the admin/etc). Even if you want to take the approach of trimming down an existing app like Marble ERP to by securely multi-tenant using the multi-organization functionality it would require a lot of work. Some of it has been designed for this and tested fairly thoroughly, but not much of it… it just isn’t designed for that.
Much of the data model does not even have adequate ownerPartyId or organizationPartyId types of fields required for multi-org filtering. You can see the ones that have been used, and refined over time by certain larger Moqui users, here:
As you can tell, I have a little trouble even trying to answer this sort of question in any simple, clear, brief way. Early on Moqui had a variety of multi-tenancy using a single app server (or app server cluster) and separate database instances. Even that approach just had too many issues and become troublesome to both build and maintain (hundreds of hours wasted on that… because it became clear that more hundreds of hours would be needed for secure tenant isolation), so it was removed in favor of the multi-instance approach.