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
