[rules-users] Building our own UI for Drools

[GPatel at tsys.com]

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 at redhat.com]
Sent: 11/16/2011 05:14 PM ZE8
To: rules-users at 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-tp3508849p3512037.html
> Sent from the Drools: User forum mailing list archive at Nabble.com.
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users

_______________________________________________
rules-users mailing list
rules-users at 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