[rules-dev] Package based import/export in Guvnor
Michael Neale
michael.neale at gmail.com
Sun Aug 8 20:48:56 EDT 2010
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 at 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 at lists.jboss.org [mailto:
> rules-dev-bounces at 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 at 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 at lists.jboss.org
> >> [mailto:rules-dev-bounces at 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 at redhat.com
> >>> <mailto:jliu at 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 at redhat.com
> >>> <mailto:jliu at redhat.com>
> >>> > <mailto:jliu at redhat.com<mailto:jliu at 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 at 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 at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-dev
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
--
Michael D Neale
home: www.michaelneale.net
blog: michaelneale.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20100809/3295b53e/attachment.html
More information about the rules-dev
mailing list