[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl-dev] Customising and versioning
Marc, Interesting comments - and reflects typical practice. I'm deep in these trenches - and the "no added value" is a loud bell here! I've been working the past few weeks on automated regression testing tools using CAM and XML to attempt to reduce significantly that cycle cost. The idea is this - you take a "happy path" XML transaction - then run it through a batch process using CAM template and a bunch of xslt scripts with includes of variables that CAM then runs - and generate lots of deltas of the happy path to test all the variences in the data stream that you need. By using the CAM template and xslt in tandem you can prune and extend the content very flexibly using dynamic parameters and batch scripts. Obviously as you note - for large transactions and complex processes - this is non-trivial to setup. The transactions are then submitted as a batch to our test environment server using our S2S Hermes client setup. On the backend we then run an Oracle extract XML utility to dump each transaction out of the database into an XML log - including any validation warnings or errors. Finally we use an xmldiff command line tool - to compare the XML logs with the original XML logs from the prior runs. I'll post some sample CAM, xml and xslt to the CAM TC docs' list later today and send out the link for those that are interested in these test data generation techniques. Cheers, DW -------- Original Message -------- Subject: RE: [ubl-dev] Customising and versioning From: "Marc de Graauw" <marc@marcdegraauw.com> Date: Tue, September 12, 2006 8:19 am To: <ubl-dev@lists.oasis-open.org> Fraser Goffin: | Personally I wouldn't change a namespace for a minor revision. A | namespace change is a 'breaking' change and means that implementers | end up having to either a) upgrade their processing logic, and/or b) | support multiple concurrent versions which have much greater churn. +1 on this one. A common scenario for a minor release is added functionality which not every exchange partner uses. We once proposed changing namespaces for minor versions, but this means exchange partners which do not use the added stuff need to use new schemas. And this requires testing the interfaces again. I don't think it is realistic (unless you can force them) to expect exchange partners to test their interfaces when there is no added value at all for them. In principle those tests could be simple and mostly automated, in practice in larger organizations tests are not automated and testing a set of interfaces is a big and expensive job. Marc --------------------------------------------------------------------- To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]