Hi,
Oops I had missed out this mail L
Ultimately it is about Rules always J. But
if business user also authors the rules then we need to package some meta-data
too. In my case the dev team would also author the meta-data which the business
user would need. E.g. package definition being done by dev team whereas adding
a new package is not allowed for the business user. This meta-data would be
primarily be driven by the solution architecture.
Thanks.
Regards,
- Nimesh
From:
rules-dev-bounces@lists.jboss.org [mailto:rules-dev-bounces@lists.jboss.org] On
Behalf Of Michael Neale
Sent: Monday, August 09, 2010 6:19 AM
To: Rules Dev List
Subject: Re: [rules-dev] Package based import/export in Guvnor
yeah - that is a valid case.
In which case it isn't just
cloning things so much as migrating for management purposes... so perhaps not
all the metadata that is in JCR is require - its all about the rules themselves
for that purpose?
On Mon, Aug 9, 2010 at 10:21 AM, Jervis Liu <jliu@redhat.com> wrote:
On 2010/8/6 19:37, Nimesh Muley
wrote:
> Hi,
>
> In my experience having implemented this functionality, there is much more
to import-export of rules than what meets the eye.
>
> When we look at Dev - QA not everything goes. This is purely based upon
what is it that we are releasing to QA and only those many rules /
configurations would need to be sent across.
>
> Then we ship from QA to client site (maybe directly to staging or
pre-staging depending upon how much testing is being done at client side).
During this time we would typically export everything from what is QA passed to
client. The challenges faced during this transition increases manifold when the
"business" user is allowed to define a rule (apart from developers).
SO what this means is that in the destination repository there may be
additional rules than what we are shipping with. But the object structure is
new one. This is not related to drools per se but nevertheless is an issue
faced during export-import.
>
> Lastly we move from staging to production. Here the export and import is
now a business user choice. Typically the business users would prepare some
data on the staging and run some business transactions to test that setup. Once
they are happy they would want to migrate the entire data setup (along with
rules). E.g. if there are 3 new banking products setup in staging and out of
those we would want to export only one product (it's data in different modules
and also rules associated with it) to the production box. The choice of
rekeying the entire data and rules does not go down well with the business user
as it may happen that there may be a mistake during rekeying of data.
>
> To summarize the additional challenges faced during export - import of
> Dev to QA - Need ability to select based on package / flags (authorized or
marked for moving to QA).
> QA to Staging - Need ability to select based on package / flags
(authorized or marked for moving to Staging).
> Staging to Production - Need API for developers to state which rules would
be exported. The list would be picked up based on the configuration UI that is
exposed by the application for exporting functional entities.
>
> If alternatively a refactoring tool can be provided to accommodate object
structure changes it would be great. This is needed only when rules are defined
by business user and hence the developer is not aware of them.
>
> p.s. Although this is dev list, I thought a user's point of view may be
helpful in development of this feature.
Nimesh, this is exactly what we want to hear from. Thanks.
Jervis
> Thanks.
> Regards,
> - Nimesh
>
> -----Original Message-----
> From: rules-dev-bounces@lists.jboss.org
[mailto:rules-dev-bounces@lists.jboss.org]
On Behalf Of Michael Neale
> Sent: Friday, August 06, 2010 4:41 PM
> To: Rules Dev List
> Subject: Re: [rules-dev] Package based import/export in Guvnor
>
> Good points and ideas. I think it is a valuable feature.
>
> On Friday, August 6, 2010, Anstis, Michael (M.)<manstis1@ford.com> wrote:
>> I'd be more surprised if companies used the same instance! Separation
of
>> PROD, QA and DEV data seems to be at the heart of many organisations
for
>> auditing, security, backup and other requirements. It gives lots of
>> "internal control" people lots of jobs.
>>
>> You could consider building a denormlalised tree in JCR representing
the
>> export; export with JCR, import de-normalised tree into the target and
>> then worry about merge\normalisation as part of the import API. Keeps
>> the "public" data JCR compliant and the described
difficulties internal.
>> Might be a better option than proprietary file format but the
temporary
>> growth in the repository could be a concern... You could consider the
>> use of a transient "secondary" repository for the
>> denormalisation/normalisation process too...
>>
>> -----Original Message-----
>> From: rules-dev-bounces@lists.jboss.org
>> [mailto:rules-dev-bounces@lists.jboss.org]
On Behalf Of Jervis Liu
>> Sent: 06 August 2010 09:32
>> To: Rules Dev List
>> Subject: Re: [rules-dev] Package based import/export in Guvnor
>>
>> Michael Neale wrote:
>>> yes, I know that - but if you don't try and export/import via JCR
then
>>
>>> you can do what you want.
>>>
>>> The "correct" JCR way to have multiple regions (QA, DEV
etc) is
>>> actually Workspaces if you read the JCR spec - it is designed for
this
>>
>>> in mind (and allows this to some extent) - but not sure how that
helps
>>
>>> with per-package stuff.
>>>
>>> IS this exporting and importing a package to a completely separate
>>> guvnor instance?
>> Yes, a separate Guvnor instance. This is because I believe, some
>> companies run different instances of Guvnor for different life cycles,
>> eg, one instance of Guvnor for testing stage, one instance of Guvnor
for
>>
>> production stage.
>>
>>>
>>> if so - JCR will not be able to be used - it will have to be a
custom
>>> file format which can be imported in the other and and adjusted.
>>>
>>> On Fri, Aug 6, 2010 at 5:12 PM, Jervis Liu<jliu@redhat.com
>>> <mailto:jliu@redhat.com>>
wrote:
>>>
>>> Michael Neale wrote:
>>> > well for category things - it could
be that if a category
>> doesn't
>>> > exist in the target "space"
then it is created, if not, it is
>> used.
>>> > There are other things though,
which are interlinked - but the
>> same
>>> > issue you bring up applies (which
is why this wasn't done a
>>> while back).
>>> >
>>> > So a simple JCR partial export
won't really do - needs to be a
>> bit
>>> > more programmatic than that.
>>> >
>>> > The question is - in the target
space - do we want to create the
>>> > missing things, or remove the links
from them as part of the
>> export
>>> > etc...
>>> >
>>> > So if RuleA depends on categoryX
and categoryY, but only
>> categoryX
>>> > (same name) exists in the target
place, then do we create
>> categoryY
>>> > there, or strip it?
>>> >
>>> Things are a little bit more complex than
this. The category (and
>>> other
>>> things like status etc) attribute is not
a plain text value, its
>> a
>>> reference type, essentially its a UUID point
to the category
>>> nodes. This
>>> UUID value is always invalid in another
repository.
>>>
>>>
>>> > On Fri, Aug 6, 2010 at 4:44 PM,
Jervis Liu<jliu@redhat.com
>>> <mailto:jliu@redhat.com>
>>> > <mailto:jliu@redhat.com<mailto:jliu@redhat.com>>> wrote:
>>> >
>>> > Hi,
>>> >
>>> > I am currently
evaluating a Guvnor feature request which is
>> to
>>> > implement
>>> > package based
import/export. The idea is to use this feature
>>> to move a
>>> > rule package from the
DEV repo to QA to Stage to the Prod
>>> repo. For
>>> > details please check
>>> https://jira.jboss.org/browse/GUVNOR-311.
My
>>> > initial investigation
shows that it is not possible to do a
>>> single
>>> > package import/export
technically. A single package in
>> Guvnor
>>> > repository
>>> > is never a
self-contained unit. For example, every asset
>>> under the
>>> > package has a
mandatory attribute which is a reference link
>> to
>>> > category
>>> > information. In
short, package can not be exported/imported
>>> as long as
>>> >
>
> --
> Michael D Neale
> home: www.michaelneale.net
> blog: michaelneale.blogspot.com
>
> _______________________________________________
> rules-dev mailing list
> rules-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
> MASTEK LTD.
> In the US, we're called MAJESCOMASTEK
>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Opinions expressed in this e-mail are those of the individual and not that
of Mastek Limited, unless specifically indicated to that effect. Mastek Limited
does not accept any responsibility or liability for it. This e-mail and
attachments (if any) transmitted with it are confidential and/or privileged and
solely for the use of the intended person or entity to which it is addressed.
Any review, re-transmission, dissemination or other use of or taking of any
action in reliance upon this information by persons or entities other than the
intended recipient is prohibited. This e-mail and its attachments have been
scanned for the presence of computer viruses. It is the responsibility of the
recipient to run the virus check on e-mails and attachments before opening
them. If you have received this e-mail in error, kindly delete this e-mail from
desktop and server.
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
Michael D Neale
home: www.michaelneale.net
blog: michaelneale.blogspot.com
MASTEK LTD. In the US, we're called MAJESCOMASTEK ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Opinions expressed in this e-mail are those of the individual and not that of Mastek Limited, unless specifically indicated to that effect. Mastek Limited does not accept any responsibility or liability for it. This e-mail and attachments (if any) transmitted with it are confidential and/or privileged and solely for the use of the intended person or entity to which it is addressed. Any review, re-transmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. This e-mail and its attachments have been scanned for the presence of computer viruses. It is the responsibility of the recipient to run the virus check on e-mails and attachments before opening them. If you have received this e-mail in error, kindly delete this e-mail from desktop and server. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |