I tried this a year ago and my build was shot and I didn't have time to figure out why. I just upgraded again and it is hosed again.
There are 2 major problems:
1) It seems like the scheduled tasks are no longer working. The projects start- (I am using FBCMD) but the text in the console window starts getting indented so I can't see what is going on. But the project never finished- it just hung.
2) I tried the project manually. It started, but is having problems with XML parsing (which worked in FB5). Here is the error:
Loading XML file c:\onesource\weeklybuild\build_tools\FB_Temp\BackupServers.xml
Error selecting node: Expected token 'EOF' found ':'.
/xml/rs:rs-->:<--data/z:z:row
I've attached a document that shows how the tasks are configured in FB6. These tasks were originally created in FB5.
There have been quite a few fixes in recent weeks to fbcmd, and we will be issuing an official update this week.
As for the xml problem, without seeing the xml it’s hard to say, but it looks like your xpath is wrong, do you actually have a document root node called xml? If so, then you may need to specify the namespace there too : /rs:xml/rs:data
If you send us (or post here) your xml file we should be able to figure out the correct xpath.
The XML iterator I have set up is a child of an ADO execute stored procedure task which returns an XML file. So the XML file I am parsing is a product of that task.
I have attached a sample XML file for review.
The XML parsing is more critical for me to figure out. As far as the jobs not running- that might be a result of how I created them (or didn't create them). I just renamed all of the FB5 references in the existing tasks (like the path to the exe, the exe and the project extension) to FB6. If I get the other problems worked out and the job still won't run- I can try re-creating from scratch in FB6.
Hmm. I wonder now if I didn't originally set up my project in a way that it shouldn't be. Let me explain.
When I first started experimenting with FinalBuilder (v4) I wanted to interact with the database to set variables. So- I used these tasks:
ADO Execute Stored Proc
XML Node Iterator
Read XML Value to variable
When I first set it up- I thought I should have been able to use the XML Node iterator step directly to set the variable value using the "Set variable to value of an attribute" option. But I seem to recall not getting that to work. But I was able to arrive at the results I needed (setting a variable) by setting the XPATH in the iterator step and using that to set the variable in a child "Read XML Value to variabe" step. And this method has worked for me for the last 2 years- up until now.
Well, I just tried setting the variable directly from the "XML Node Iterator" step (and not the "Read XML Value to variable" step), and it seems to have worked. I wonder if I should change all the tasks in my project to do this.
I just tried your xml here with the exact same settings and it worked fine. I have attached my sample project, please try this (adjust path to file accordingly).
Can you check which version of msxml you have installed on your system?
Ah, looks like you figured it out while I was on the phone!
Getting the attribute value directly from the iterator action would definitely be the preferred way, faster than using more actions. The only time I would use the xpath to variable option is if I wanted to do further iteration or manipulation of the node while iterating.
I did notice though- that the indentation problem is still occuring. What I mean is that child-tasks are indented in the console display so that if you have a lot of them in a hierarchy the text moves off the console- far to the right. It would be nice if it would all stay in the window.
Thanks for the feedback. As for the indentation, that’s something I’m not sure we can do much about, unless we remove the indentation altogether. We did actually make some changes a while back so that the output doesn’t disappear completely if your indentation level is too high… that seemed to confuse the windows console api’s to the point that the app would hang… as long as some characters were in view it was fine. We may add an option to disable the indentation.
I just added a -H option which turns off Hierarchical logging for fbcmd.... turned out to be trivial to implement due to the design of our logging architecture. Official update should be out today.