Hi!

I want to do something “irregular”. I have to put a list of ~100 entries into a String Table. Since I don’t want to enter them manually, I go to the wM’s file system and edit the flow.xml file of the service (and yes, I do that carefully…)

Now, when I open the service in the Developer, it is still as before. In other words: the developer must use some kind of PC-local cache.

Does anyone know where that is? So that I can delete that in order to force the Developer to newly get the service information node.ndf and flow.xml.

cheers,
fcctr

Try reloading the package or refreshing the developer with the Refresh button to the left pane in Developer.

Cheers,
Akshith

The flow.xml is the persisted service definition in the filesystem of Integration Server. Therefore you need to do 2 things in order when editing the flow.xml

• Reload the package the service is in in the IS console
• refresh the IS display in Developer

Maybe you should use a “restorepipeline” and modify this pipeline instead of playing with the flow.xml

If your end goal is to load those strings in to the string table, with out manually entering them, Did you consider reading them from a file at runtime and storing in to a stringlist…??

Hi!
Thanks. I’m sorry that I forgot to mention that I already tried refreshing in the developer as you said. I even tried with restarting the Developer.
No success.
let’s check the other replies in the thread.

cheers,
fcctr

Hi, mwroblinski!

Yes this should do it. I had - due to other reasons - to restart the whole IS. And after that my manually inserted changes were there. If I read your posting, it’s easy to figure out why.
However, restarting the IS solely for such a small problem as mine is quite invasive. So your steps are to be preferred, since they are more focussed on the actual problem.

Thanks a lot.
fcctr

Hi!
Yes, that’s basically the end goal.
Yes, I also considered storing the values in a file and reading that file at execution time. I even thougt about using a database.
However, it’s “just” around 100 values.
So I decided against the database solution, since that would possibly be too much of an administration and performance overhead.
I also decided against the file-based solution due to the administration overhead. You now maybe wonder: what overhead? Well, I would then also have a file on the filesystem, which I have to administer. That wouldn’t be the problem if I would be the only one to administer the IS and the other involved admins would be as disciplined to use Deployer, etc. in order not to forget about this file lying 'round somewhere (well actually not somewhere, but e.g. in the resouces directory of the package).
Anyway, if relying on an external file, you also have to be careful when turning on the results cache.

Thus, I opted for the in-service solution, even if it is not the best one - also from an administration point of view… (What if the list has to be updated…)

Thanks for your useful input,
fcctr