Hello everybody:
does anyone have a good idea of how to effectively do version control for WM Enterprise Integrations. Also typically we do backups of the Broker-guar and Broker-pers files, which doesnt give a good way to recover specific integrations. Anybody have any ideas around that?
Thanks for your help
rather than backing up the broker-guar and -pers files you can use the broker_load and broker_save command line utilities.
The storage files will backup all brokers running on the same enterprise server instance whereas broker_save will target a specific broker.
You can also export from the EI (VI) into adl files. There are specific rules that describe what is exported for each type (Integration Component, Integration, Configured Operation, Operations, Adapters, Document Types, and Document Scopes). There is a GEAR document that covers some of it and gives you an idea of the complications involved.
If you use ATC you have to export the blueprints and rulesets separately into xml files using the flow_architect. Keep in mind that you have to re-generate all the rulesets after you have imported them into a broker (Annoying hassle that takes about 8 mouse clicks per ruleset).
As you have gathered by now there is no way to effectively do version control for WM Enterprise Integrations if you use the WM development tools.
If you use ATC and java workunits then you have the same control you have over normal code. Adapters will still be configured using tools.
If you learn a more efficient method, then please share. This is one of the limitations of WM and their tools.
We wrote a utility that uses the java BrokerAdminClient to import/export wME artifacts to adl files. Each artifact is really stored in the repository as an event type. You can use the Event Type Editor to see where they are all stored. Look under the ActiveWorks event scope.
Once exported each artifact is individually version controlled.
The biggest advantage to this approach is it is automated and repeatable.
The order of export is not important, but it is for import. The following are in the proper import order.
NOTE: the configured, common, and scripted operations consist of an input and output event type. We export both to the same file.
Hi, John G:
Using your approach, many files will be created for version control. Or there are too many Configuration Items for the version control. Could you indicate what Version Control Tools you had used? Do you have any experience in using Rational ClearCase for the version control of wM components?
Thanks.
Well, now I have to ask the same of you, ZGW: Do you have experience using Rational ClearCase for version control of webMethods components?
This is an ongoing discussion point and I would like to hear how others are approaching the same issues.
We used source/version control system on windows it was Visual Source Safe adn in Unix I sed Perforce P4 on one project and I store all packages and services at WM file level soI can recover and update only single service if I need to. But it requires care and deep knowledge of WNM service structure and directories on part of all developers. Although this information is available in WM manuals people do not bitrher reading it…
Thanks, Igor. I went to the Perforce Web site (http://www.perforce.com) and saw a wide platform support base. I also saw the P4Win product that you used in your Windows environment.
Do you mind talking a little bit more about the Perforce product and how it operates? Because the software is cheap (and free to some users), this may be a viable alternative for some webMethods users as oppposed to using software from Configuration Management giants such as Rational.
Thanks,
Dan.
I would recomend to plabne development and source control at package level rathere thatn file level saves alot of hasle.
On windows I used Microsoft Visual Source Safe but P4 exists for Windows too. P4 is overall good product but its a bit difficult to use and learn. Once you get used to it its ok.
The main features are flexibility, we used lables to build a certain patch or build version. Isued P4 server on SOLARIS and clients on windows. It is complete GUI operation but P4 also has scripting interface for UNIX admins and ops to hook into build scripts. We did exactly that extracting builds and releases from P4 using scripts adn pushing into various environments. But I consider thoses scripts are woodo magic
Overall its good solution however I would recomend on Windows to use V Source Safe. On UNIX there are flavors of RCSS that are also free althoug all command line only.
Problems:
P4 had many problems, Users working on files concurrently you can checkout same file you just cannot check it back in!
There is no automatic merging capabolity with versions it axists but very rudementatry and its easy to make a mistake and overwrite somebody’s code.
Disc space capacity is critical got to have disk allocated otherwise P4 goes down. understanble no space to write files. THe lable and release creation is a bit hoacky got to know exact steps. With P4 do not deviate from the path! One wrong step panishes you. P4 keeps a local mehta data DB on your client for your stuff and on several ocasions this repository mehtadata that keeps info about my 4000 files get corrupted, recovery is difgficult! Got to run scripts localy only command line to destroy mehtadata and Refresh your code from server, back up new code the ovewrite, veru messy [process and error prone.
Hi, Dan:
Some of my colleagues had used other Version Control Tools (e.g. PVCS) for wM Event Type files as described by John. Now, our clients ask us to use Rational ClearCase as Version Tool for wM Components. Because this is the first time for us to use ClearCase, I am searching whether someone here has any experience. We’ll try to do something using ClearCase. When we make some progresses, I’ll put our experience here.
ZGW, wrt your concern about the number of artifacts:
True, the number of files can be rather high. However, this is really no different from managing source code files for a “regular” development project. The approach presented by John G. provides the maximum flexibility and the minimum coupling (from a source control perspective). The key is to trade off manageability (which dictates fewer artifacts) with flexibility/decoupling (which dictates more artifacts).
Isn’t there still a version of VSS for Unix? I used it on a team a few years ago. We had Windows and Unix clients running VSS against a single repository. The repository was hosted on a Unix box and the Windows clients used an NFS client to access the Unix volume. It worked well (after a failed initial attempt at using Samba).
Igor, wrt your reference to “plan development and source control at the package level rather than the file level”, what do you mean? What are you referring to as a “package” in Enterprise Server?
You also make reference to “WM service structure” and a creating a “patch or build” version. I get the feeling you may be referring to Integration Server (B2B Server), not Enterprise Server, which is the topic of this particular forum, so I thought I’d check.
Igor, thanks for the review. That is really helpful information. If others venture into the Perforce realm, I am sure your tips will come in handy.
ZGW, you and I seem to be on the same path. There have been some rudimentary exercises using ClearCase with Enterprise Components and I will dig up what I can and post it. The main issue for our Configuration Management team is ROLLBACK. If something goes wrong, the ability to rollback to the last certified environment is crucial.
Hello, I hope someone notices this…
We are in the process of setting up our Source control structure for webMethods. Can any of you webMethods “veterans” please recommend a folder structure that will support source for IS, ES, Mainframe, Workflow, etc… ??? (we will be using CVS for Source control)
I have searched through the forums, and read the GEAR docs, but now I’m looking for stuff that works in the real World (no offense webMethods).
Our company will be using a 3-stage promotion model (Dev, QA and Prod). Within our company we have many business units (eg. Investments, Wealth Management, etc…). Each of these units will have webMethods developers. Our plan is to give each of these units their own logical Enterprise Server and 1 broker. The Business unit logical servers would be put into a Territory, since integrations will cross business units.
Currently there are no plans to give each business unit their own IS, Workflow or Mainframe server, but that may change with version 6.
Right now all of our development is using ES and Workflow, but we are planning on using all components at some point.
Sorry for blabbing on.
If anyone has anything to share please let me know.
Regards,
Wayne
John G,
Can you mind sharing the Utility you guys have developed. I would be interested to have a look at it and understand how we can manage Version Control here.
One of the headaches that we are currently trying to overcome is version control.
I will also look at http://www.perforce.com to find out how that suits us.
Thanks
Does anyone have this utility which was referred to above? We are also trying to get source code control within our ES implementations. Thanks.//David
Work Email: David.Yates@usa.xerox.com
Evening Email: whynotpizza@hotmail.com (not checked that often)
Check out the whitepapers at:
[url=“wmusers.com”]wmusers.com
i see we are all facing the same issues.
My office also has 3 environments, (Dev, UAT, and Production). And version control is a headache.
What’s more, I’ll have to forecast when we move to webMethods v6.0 later on. Currently using v4.6.
Does webMethods have a specific tool, or some kinda tool embedded within webMethods itself for version control? Or do i require a 3rd party tool instead? What’s the best recommended tool tat wM would advise?
Thanks!