Architecture on preventing EAI code overrides

Hello everyone.

I’m not sure if anyone else is experiencing this issue but I thought I would ask. We have DEV, QA, and PROD environments. As more and more people are being hired, there is a lot more hands out there that can step on/change EAI code. Our policy when it comes to changing data in our DEV environment is to first copy the code from prod to dev first, but there have been times where contractors would come in and not adhere to that, either because they forgot or perhaps wasn’t told of the policy.

Because someone else modified the data in dev prior (person could have just changed something for a test and neglected to change it back), now bad code could potentially be moved to production, which is why the policy is to copy from prod first to ensure you’re working with the latest code before making modifications. However, there have been situations where someone would adhere to the policy and copy from production first, not knowing that maybe a couple weeks ago, someone else has already done that and made legitimate mods, meaning that now that person will have to redo their work, because the recent person has just clobbered their data by overwriting it.

If the above is confusing, my apologies, but I guess what I’m wondering is whether you are or you did (in the past) have issues such as thing and if so, what kind of policy was placed to prevent people from overriding someone else’s code, considering that it doesn’t seem that Webmethods has any sort of check in/check out type logic (unless that’s what the lock is supposed to represent) and it doesn’t seem that Webmethods has any sort of “who modified last / show last date/timestamp when modified” logic either. From what I show, if the service is NOT locked, then you have no idea when it was last modified.

Like I said this is becoming more of a bigger issue as more people are hired. Passing a million emails is not a good solution.

Any ideas or any team rules concerning something like this, that you can pass on will be greatly appreciated. I could then take this to our next team meeting and have a big discussion. Thanks for your help!

Version control is critical as a team grows.

Copying from prod to dev before making mods was a reasonable thing when the team was small (and thus had good communication). But now, as you point out, you’ve outgrown that.

Integration Server and Developer/Designer can be integrated with a VCS. Review the SAG site for information and details. Be aware that this VCS integration is limited in what it does.

I’ve seen and used an approach that stored packages in a VCS. VCS artifacts and versioning were done at the package level, not the service/element level. When work is needed in a package the assigned person checked it out to work on. When finished, they check it in. Generally this works reasonably well, if the scope of the packages are not too broad. When multiple people work on a single package, they must coordinate their work (no source merge tools available out of the box).

For utility packages with broad applicability I would assign a single person that is the owner of it. All changes by anyone must be coordinated/approved by that person.

If you want something a bit more sophisticated/automated and which covers more than just IS packages you could take a look at CrossVista TEAM.

Full subversion support is on the way…

Can you elaborate?

IME, support for a particular VCS tool is a minor part. What’s far more interesting are what are all the elements that are supported and the functionality. The built-in VCS facility provided by SAG supports a number of VCS tools but the elements and functionality of the built-in functions is quite limited. Indeed, IMO it’s all but useless.


webMethods product road map for 8.x was given by Susan Ganeshan at the integration world which had a reference to supporting subversion.

Currently there is a WmSubversion package but it has lot of issues which is not entirely supported by SAG.

I hope with Subversion support, we would be able to checkout-checkin flow/java services from SVN like a normal java based development approach.

DIFF/MERGE will be a challenge as flow services are XML based but if CROSS VISTA is able to achieve it then SAG can very well do it. However even without DIFF/MERGE, if we could do checkout and checkin then it would save considerable time in version management at the service level rather than at the package level as more than 1 developer can work on a single package.

Currently I am drilling out any documentation reference as to what exactly would be supported.


Thanks for the clarification. Full SVN support by the “VCS Integration Feature” from SAG is already here.

SVN support is in 8.x (did some work with it last year). No additional functionality is provided beyond what was available with the VCS facilities before. This is just support for another repository tool.

The document “Storing Services in a Version Control System” describes the functions provided and the limitations (same for both Developer and Designer). Checkout/in is pretty much all that is provided.

Many people get excited about the “VCS Integration Feature” because they envision it will be like what they’ve worked with before when coding Java, C/C++/C#, etc. Invariably they are disappointed because IS, TN, Broker, Designer, etc. development is quite different from developing text-based source code. Services are not the only element that needs to be considered for version control and deployments.

SAG/wM could indeed do something like what CrossVista has done but I’ve not seen any information indicating that it is in the roadmap.

My usual recommendation is to do something else. This facility is not sufficient. But others may have different experience/POV with this facility.

Thanks Reamon. I can’t agree more on this.
Well I think for SAG → something is better than nothing :slight_smile:

One good thing about Designer projects (CAF & BPM) is that we can use the Subeclipse plugin. It solves a lot of issues; however it needs a lot of communication and coordination when multiple developers are working on a single CAF/BPM project.

There are lot of discussions on how to divide a unit of work among developers (single Developer packages/Designer Project vs multiple Developer packages/Designer Projects) but you will never be able to precisely tell which one is better. It’s always on case by case basis.



First of all you need to have some version control system (CVS,PVCS etc). You should put all your all your latest production code into that. Each developer work space should be mapped to version control workspace (folder structure, naming etc…). Once version control system is ready with latest code ,each developer need to get the latest code into their work space.

Follow the below steps if you need to do any changes to production code.

1. Ask developer to get the latest code from Version control system by doing checkout.
2. work on the changes.
3. get it reviewed by someone.
4. Ask the developer to check in with proper comments.
5. Developer should prepare release notes mentioning about the changes and send it to Admin
6. Only admin or lead should have the access to prod /QA system for deployment. They need to read the notes and deploy.
7. As we have version changes, we can always revert if you see issues with new code