We are having some issues upgrading our flow services from 6.0.1 to 6.5 environment:
After the upgrade to 6.5, about 20 percent of our flow services are corrupt (~500 services):
the issues in the flow are:
design-time problems such as ghost variables in the pipeline (eg. twice the same document – one does not exist), or invalid types (eg. string recognized as object). Maintenance nightmare.
Run-time problems resulting in nullpointer exceptions, due to corrupt mappings (eg mapping from source ghost variable to target existing variable or mapping from source existing variable to target ghost variable…)
We are still investigating, with wM support, how these issues can be tackled. According to wM, this is due to bad memory management in 6.0.1, fixed in 6.5. The problem is thus related to code developed in a 6.0.1 environment; the issues are uncovered in 6.5.
We have been provided with a tool from wM (WmFlowAnalyzer.zip) to report these issues. The tool analyzes all flow services and inserts a comment in the flow if there is a problem. The tool also generates a report (at the package level), of the occurrences of the errors.
The errors are classified in 6 categories:
Type 1: Document exists but Type and Dimension both are incorrect in the Path Expression
Type 2: Document exists but Type is incorrect in Path Expression
Type 3: Document exists but Dimension is incorrect in Path Expression
Type 4: Source or Target schema doesn’t exist for a Map step
Type 5: Map Link in the Flow Step overlaps with the Input and Output links of one of the Transformers
Type 6: Document exists but the Position or Index in the Path Expression is incorrect
Questions are:
Can anybody explain the different type of errors at a higher level? What does this mean concretely?
Has anybody experienced these issues upgrading their environment? Do you have any pointers on how to analyse and solve this issue in a failproof manner? Any methodology you can recommend?
Taking account of the impact of the issue and the end of support coming up for 6.0.1, do you think it is smart to carry on with the release upgrade? Any ideas on how to inspire wM to dedicate resources to fix this problem?
We were waiting to see if anyone else was going to run into this problem. webMethods support had told us we were the only one so far. So far for us it has caused only minor problems. We used the tool to identify the issues and then we have gone in and manually corrected them as needed.
Some of things like the Type 4 don’t always need correcting. We asked for the more detail definitions of the errors but haven’t received it yet. Most of the fixes involved cleaning up some mapping/pipeline issues with duplicate fields/documents being present.
We talked with webMethods about an automated fix but that turned out to be more scary than doing it ourselves. I think the manual approach is the way to go. We have upgraded 4 of our 6 IS instances so far with only minor problems. I would still recommend upgrading to 6.5.
I am not sure about the memory management issue webMethods is talking about. Most of the problems are due to less than ideal development practices on the part of the developer. 6.0.1 just let you get away with it a little easier. Most of these issues are related to renaming, moving, deleting variables/documents while there were still in use in other areas. Under the covers in the xml files the references were still there(and ignored buy the IS server) but not visible in Developer(bug), in 6.5 this changed so the problems are now visible and not ignored by the IS server.
We have the same problem. I called the problem doubled variables in pipeline. We contacted WM support and they redirected us to Profession Services. We are in escalation process right now, because we have more than 1000 flow services and from our perspective this is WM migration problem. I see version 6.5 in webMethods full with bugs especially part with MyWebMethods. We made rollback on our production environment because this bug. I am really disappointed from WM. we had to do rollback in 2 AM in the morning. This is happening for the first time in my programming career (In general things where out of the control, maybe this is normal for programming business).
We are upgrading from Wm 6.1 to WM 6.5.
We started manually to looks over each service for incorrect data in parallel with WM investigation, because I don’t see other feasible option right now to overcome this issue. I will keep you posted if we have new info. I hope WM to improve there development process, because products are full with obvious bugs.
WM support told us that Developer 6.5 is enhanced to show all hidden variables in pipeline. That is why we don’t see such behavior using 6.1 products. But I am sure these invalid pipeline variables are created from some bug in Developer 6.1, created but not active. And most of the time we observed such corrupted data using copy/paste functionality of Developer 6.1
Okay so 6.5 did have some bugs especially in the MwS piece(okay some really big bugs, I’m not sure it was even tested before shipping because it certainly didn’t work out of the box):mad: . I don’t think there are two many fans of that particular product. But we have upgraded all of our 6.0.1 envs. to 6.5. We haven’t had any production issues, very stable once we got past the MwS issues.
The pipeline variable issue is actually a developer coding issue from what we have seen. It comes from inconsistent pipeline management. They really are not hidden variables but variables that were renamed or dropped or dereferenced in a inconsistent manner. 6.0.1 and 6.1 just kind of let you get away with it even though the variables still existed in the flow.xml.
The utility they provide to identify the issue was helpful to us. We used that to go in and correct the issues. It was tedious but didn’t take to long. We have a lot of flows as well. Regression testing was the pain but you have to do that anyway with a major upgrade.
Thanks for sharing your experience with us. We continue to edit all services manually. And regression testing + User Acceptant Testing is currently upcoming. It will be a loot of work, just for single bug.
You must obtain all webMethods software, directly from webMethods. Please do not ask other wMUsers members to send you WM software as it violates the wMUsers terms of service and your webMethods license agreements.
This thread talks of issues in the My webMethods Server. We are doing a 6.1 to 6.5 WM upgrade at our organization. Could you let me know what problems I should look out for on MwS? Though we are not using this component, I wanted to check if there is some inherent dependency on this component in Wm 6.5.
Also, how much does the WmFlowAnalyzer help or more importantly reduce the time required for the upgrade? I am getting a mixed reaction from this thread.
If I understand your question. Your organization is in the process of upgrading from I.S. 6.1 to 6.5 (and your organzation is not using MWS right now).
MWS is kind of independent here. However, two of the interfaces WmBrokerAdmin (Broker Administrator) and WmMonitor (BPM) have been moved to MWS.
webMethods did supply a fix to get the WmBrokerAdmin 6.1 to continue to work on I.S. 6.5.
But for WmMonitor (BPM), you have no choices but to use MWS