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 <[email protected]> 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: [email protected] [mailto: > [email protected]] 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.)<[email protected]> > 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: [email protected] > >> [mailto:[email protected]] 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<[email protected] > >>> <mailto:[email protected]>> 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<[email protected] > >>> <mailto:[email protected]> > >>> > <mailto:[email protected]<mailto:[email protected]>>> 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 > > [email protected] > > 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 > > [email protected] > > https://lists.jboss.org/mailman/listinfo/rules-dev > > _______________________________________________ > rules-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-dev > -- Michael D Neale home: www.michaelneale.net blog: michaelneale.blogspot.com
_______________________________________________ rules-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-dev
