On hosted mode:
I have the same requirement i.e hosted site with lots of external clients using the same
site, it is indeed impractical to deploy a guvnor instance for each client. Overall, from
what I have researched, there are two things available to segregate rules by external
client: categories and packages, but I decided against using them to achieve client
segregation. The approach I have arrived on is to launch the guvnor standalone editor from
my website, store the brl in my tables (the standalone editor provides javascript hooks to
allow retrieving the rule brl/drl once the rule has been written). Effectively, the only
thing stored in the guvnor repository will be the model to enable rule authoring.
Originally, I was planning on storing the rules in the guvnor repository and using the
rest api to list rule packages (prefixed by clientId) in my site. Since I am able to
retrieve the brl/drl anyways (via standalone editor javascript hook, or if that feature
were not available, then via rest call immediately after rule has been authored), I
decided to store the brl/drl in my app db. Since the rules are stored in my tables, I will
have full control over client segregation.
I have done a mini-POC to prove that this will work and it seems like it will, unless an
expert on this mailing list can point out showstoppers/potential flaws/shortcomings of
this approach.
Hope this helps others who are faced with similar situations.
Thanks
G. Patel
----- Original Message -----
From: Jervis Liu [jliu(a)redhat.com]
Sent: 11/16/2011 05:14 PM ZE8
To: rules-users(a)lists.jboss.org
Subject: Re: [rules-users] Building our own UI for Drools
On 2011/11/16 16:37, kapokfly wrote:
Thanks for the information.
Deploy multiple GUNVOR instances can't resolve our issue as we have
thousands of companies as our customer, each company will share the common
part of our applications and meantime they can customize objects/fields they
have permission with, this will be terrible if we go with the
separate/dedicate deployment and basically we think that will be not
manageable...
What we are looking for is, be able to share a common collection of ruleset
and at the same time, be able to define their custom rules with their
customization.
At the moment, it is possible to achieve this by using
role-based-authorization in Guvnor. I.e., you create some common
packages that are designed to be shared by everyone. You assign
package-readonly permissions to everyone so that they have read-only
access to these common packages. You can also use Global Area to achieve
same effect. Essentially Global area is a special package that can be
shared by all packages. Then each user has package-admin permission for
their own packages.
The "Workspace" as I mentioned early will provide a more completely
isolated environment for each user when multiple users are sharing one
instance of Guvnor. However we dont have any concrete stories planned
for this yet.
Cheers,
Jervis
Ivan
-----
Ivan, your Panda, forever
--
View this message in context:
http://drools.46999.n3.nabble.com/Building-our-own-UI-for-Drools-tp350884...
Sent from the Drools: User forum mailing list archive at
Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
-----------------------------------------
The information contained in this communication (including any
attachments hereto) is confidential and is intended solely for the
personal and confidential use of the individual or entity to whom
it is addressed. If the reader of this message is not the intended
recipient or an agent responsible for delivering it to the intended
recipient, you are hereby notified that you have received this
communication in error and that any review, dissemination, copying,
or unauthorized use of this information, or the taking of any
action in reliance on the contents of this information is strictly
prohibited. If you have received this communication in error,
please notify us immediately by e-mail, and delete the original
message. Thank you