I have seen this missing end tag error in Developer for 4.6, 6.0.1, and 6.1 webMethods IS. Is this fixed in 6.5?

When 2 developers are logged in under the same ID and editting a service from different machines the flow.xml and flow.xml.bak files do not write the complete file on a save. The bottom part of the file is missing. This becomes evident after both have logged off and get back in after a period of time. In the IS admin, under package management, you will find that the package is only partially loaded and flows have “Missing end tag” as the reason it will not load. The recovery is to delete the flow and start over or restore from backup if possible.

Perhaps the save should be more robust to not cause a bad file to be written in this scenario, but I have to ask… why are 2 developers using the same ID and why are they editing the same service at the same time? This seems to be just asking for trouble.

I know it sounds stupid on the face of it but there are occasions where only one ID is made with access to update a flow in a certain environment. When the call goes out that this flow has an error, multiple people will log in (sometimes remotely) using the same ID. I have seen this over and over.

Sometimes, the flow was locked by someone who is not available (but left their machine on and Developer running). When the 2nd person looks at it, they decide to log in as the same user instead of unlocking the flow. Usually this happens because the 2nd person is only allowed Developer access and gets the password from the 1st person in order to solve a problem.

Yikes.

Sounds like the the solution is a better process, not software fixes.

In this situation who ever have Administrator rights can unlock that service and help the 2ndPerson…isn’t it can be solved internally??

HTH,
RMG

Jonb,

Not only is having multiple users use the same ID in any server a bad idea, but it appears to me that you guys are doing this to edit services in a Production-type environment. Is that true?

If so, then this makes your situation even worse. In addition to assigning each user their own ID, you should make an effort to employ a deployment strategy so that services can only be changed in Production (or, really, any environment other than Dev) via a formal deployment process. I mean, just the mere fact that

should indicate that what you guys are doing was not originally intended to be done.

• Percio