I am new to webMethods and could be completely wrong here, but reading the documentation about how to versioning services/any code seems a bit peculiar to me. Is it really true that the only way you can integrate with a SCM is by zipping up files? What if I want to roll back a version of some java code I created? doesn’t sound too much to ask for to me. Maybe I am just not used to these integration platforms, but what happened to checking out a file from CVS fixing the code and checking it back in?

thanks Morten

Hi Morten,

this is already discussed in the Wish List Forum (Search for “Version Control”).

At the moment the only recommended way is to repeatingly create zip-files for your packages and store them in CVS. But there is an Appendix H in DeveloperGuide pointing to SourceControl.

webMethods has announced support for this feature in the upcoming webMethods 6.5 Platform scheduled for April 05.


Could anybody possibly provide a little information on how this (the SCM Integration)is going to work? I’ll beta test it if necessary. This is a really big deal for us.



Unfortunatley we all will have to wait for the GA release.

FCS exists, but webMethods is very restrictive with its distribution.


Well, that’s certainly webMethods perrogative. I suppose the deails of the SCM integration are either subject to change or a trade secret?

If I seem frustrated, I am. This is the single largest problem I have with the toolset and it does negatively impact the perception of the tools here at my organization. There’s a huge difference between saying “but they say it will have it in April” and saying “They’re delivering it in April and it will work this way”. The second one carries a great deal more weight, and may also give me some clue as to what I might do in preparation for this feature.

We use CVS on the packages in /packages/PackageName and that covers what we need to do.

How many developers do you have and do you use a centralized development server or individual Integration Servers for each developer?

Thanks everybody.
I guess we will have to wait.
I am curious though. So I accept that I have to export a zip file, fine. Where is the “import package” menu item?? I have to go on to the server with administrative rights (or at least rights I currently do not have) and re-install the package, how odd is that! I thought one of the ideas with exporting to a SCM was so you could easily roll back changes.

Also if I lock for edit, I don’t see any “revert lock”, forcing me to make a save even though I did not change anything. What if I lock 4 files, make some changes and decides that the work is too complicated and just want to “undo” the changes? Am I just missing something here??

-thanks again everybody


The simplest way to do change management is at the package level but it’s not the only option.

Hi Morten,
We are planning to use WmDeployer insted of CVS to do our Source Control. It’s hard to implement because you have to plan and configure deployment sets, build maps and so on to have it working fine but seems a interesting solution mainly if everybody is working in the same IS. Have you consider this way?

I’m not looking for bandaids, and I’m not looking for solutions that support one or two developers per integration server. I want the same kind of integrated revision control and change management that every other major development tool we use has had for years. I cannot craft a howto that says “If you’re not sure if you will want to promote thse changes, copy and paste a few flow services…”

My problem with a solution like CVS (or subversion or perforce or Darcs or whatever) is that it’s out of band. My other tools know when I’m working in a controled workspace, and they give me feedback about the state of the objects I’m viewing and editing, and in-place functionality to manage that state. New objects are automatically added to SCM. Moved and deleted objects are likewise dealt with. I don’t have time to hand manage this.

Incidentally, all of this could probably have been achieved in Developer 6.1 simply by exposing developer activities (new, view, lock, unlock, save, delete) as events.

Thanks wkriski.34406

Maybe it is here I am uncertain, I am getting closer though, or maybe I am getting used to the “webMethods” way of thinking.

You say – All you do is reimport version 1.2 and you’re good to go –

it’s the reimport I am not sure about. I have seen it being done by deleting a package from the server (say v1.3) and reinstalling it again (v1.2) but can this be done through the Developer in a snap or do you need to be on the server?

You’re absolutely right.

We appreciate your desire for tighter version-control system integration. Ultimately, in order to deliver SCC integration to the fullest degree, we need to make changes to our tools and the way our tools interact with the development time assets. As we have announced in our roadmap presentations at Integration World, we are planning comprehensive SCC integration with our future webMethods 7 release.

In the meantime, with our next release of Integration Server, we will be offering the following:

  • Ability to hook into the popular version control systems directly via a separately installable package to the Integration Server (labeled WmVCS.)

  • Direct integration into Perforce and Microsoft Visual Source Safe

  • Extensible scripting support to adapt the WmVCS functionality to other version-control systems (Clear Case, PVCS, CVS, etc)

  • Ability to checkout, checkin, revert, delete, load current, load by date/revision/label, and lock status on all favorite Integration Server elements including Flow, Java, C/C++, Visual Basic, Flat File Schemas, Triggers, and Documents

  • Parallel development support with multiple Integration Servers can interact with a single, shared version-control system

These features will be made Generally Available in late May and we will offer preview to select customers in late April or early May.

Kerry Lenahan
webMethods Product Management

Thank you. This is EXACTLY the kind of information I was looking for. As far as I can see, this feature set will address all of our major pain points.

We have six developers using IS. Although we do have a development server, some of us have our own installations that we use for development. We talk to each other about changes we might be going to make to common packages to ensure there are no clashes.

If someone has made changes to a package, we simply update it at the file level from the repository and reload the package. By file level, I mean /packages/

If it is a new package, we check it out of CVS into the packages directory, then use “Activate inactive packages” from the package management page of the admin website.

We tag all files for each release, and could revert to that by deleting the package then checking out at the desired tag.

I hope that helps.

Kerry, regarding the points you listed regarding SCM support in upcoming 6.5 release, I need clarifications:

  • Ability to hook into the popular version control systems directly via a separately installable package to the Integration Server (labeled WmVCS.)
  • Extensible scripting support to adapt the WmVCS functionality to other version-control systems (Clear Case, PVCS, CVS, etc)
  1. We are about to purchase StarTeam, and I am wondering now how it will hook in this WmVCS package. Are you aware of this particular SCM and if it will work with 6.5 ? When you say popular SCMs, do you include PVCS ?

  2. Is it possible to detail a little bit more on the “scripting support to adapt the WmVCS” ?

Thanks in advance,

Would it be possible to post the requirements/setup instructions prior to the release of the WmVCS package?
I imagine the setup requirements will take groups at least a week to accomplish and we would like to start on them as soon as possible. We’ve already begun installing clearcase client on our development server as I’m sure that will be required.

We have a number of issues caused related to wM lack of support for configuration management. In my organisation we have a team of around 30 developers operating on a single server in a multi shore scenario.

The big issue for us is we are trying to create a framework of reusable components and that means for us multiple developers making multiple deliveries into production.

Having waited for the WM SCM package for ages we have decided to attempt to create zip files manually and put the underlying elements flow.xml and node.idf files under source clearcase source control.

Another advantage of this is that we also can control the manifest files content based on real version numbers from our SCM system.

I’d be interested in hearing from anyone that has similair thoughts.


PS: Wouldn’t it be cool to have a flowdiff tool?

The flows are text files. So you can use a text tool to do a diff like windiff. Good day.

Yemi Bedu