Hello all

I have an annoying problem…
Let me first sketch our setup.
We have a TST broker where we develop and test our integrations. When they are finished and work correctly, the integrations are imported to a PRD broker where they will work in our production environment.
Incoming directories, write directories will change when exporting to the PRD broker

Now the annoying problem: whenever we import a new version of an integration to our PRD broker, ALL integrations will have their TST broker values for incoming directories!
We ‘only’ have 4 of these operations so far that change, but it’s annoying us already and we fear the day that we will have to change 20 operations whenever we import 1 tiny change…

Is there some sort of link between certain components? (they are in the same integration folder, but are different integrations. All operations work with same IOAdapter and AS400 adapter)
Do you guys/gals also have this problem? Or did you solve it?
Thanks in advance ! I really want to get rid of this problem !

It depends at what level you are exporting your ICs from EI.
If you select an individual IC, then export it, it will copy the IC, all Document Type Defs used by that IC, all configured operations used by that IC, all scripted operations used by that IC and all common operation definitions used by that IC into the resulting ADL file.

If you export from the IC folder level (i.e. select the folder then export it) it will do this for all the ICs in that folder.

It sounds like you’re selecting the folder then doing the export, instead of just selecting the IC you want to move, then exporting to ADL.

Can you confirm??

We have 1 ‘top level’ folder for our project.
Then we have a folder for each of the sub-projects and each sub-project has several integration components.

Our problem occurs that when we select a folder of a sub-project and export it, it has influence on some (not sure about all) operations of the others sub-projects.

We have a config file that includes all of our directories and other configuration variables that change from one environment to the next. We only have to hardcode the path to that file, and we do that relative to the IS_HOME directory. If your IS_HOME is /opt/webMethods6/IntegrationServer/ then create a /opt/webMethods6/IntegrationServer/config directory and you can access it as ./config
Then if your TST environment’s IS_HOME is something like /opt/webMethods6/QA/IntegrationServer/ the ./config will refer to /opt/webMethods6/QA/IntegrationServer/config

Matthias,

that’s the problem then. Because you’re exporting from the folder level, the resulting ADL file contains all the ICs, configured ops, scripted ops and doc types used in ALL of the ICs under that folder.

I suggest that you manage the importation of individual ICs rather than the parent folder.

Select the IC, then go to File –> Export… Create the ADL file for that IC only. In this way, only the component parts for that IC will be saved to the ADL file, and when you import it into your target system it will not affect the other ICs.

Note, however, that if you make changes to shared components (e.g. a document type that is used in more than one place) or a common operation, then the modification to that part will be applied to all instances where it is used in the importation target system.

I hope this is clear. Let me know if you are uncertain about anything I’ve said and I’ll try to clarify.

Good luck!

I understand that if i select the main-project folder, that all ICs underneath are affected
But that was the meaning of using ‘sub-projects’: all ICs that belonged together, would be exported and imported together.

But if I select 1 of these sub-projects, ALL other sub-projects are exported as well… This means that ALL integration folders ON THE SAME LEVEL are exported as well

And I don’t think that this should happen? Or is that normal behaviour?

PS: I’m still not sure if they are all exported, I only know that incoming directories for file polling etc. change after I import a certain sub-project

I hope it’s clear for all of you and thanks for your help so far!

Matthias,

you have mail…

Hello all,
just wanted to let you all know that Mark and I managed to get to the bottom of this.

It appears that EI exports ALL dependencies of a certain component. But that’s not it… EI also exports ALL operations that share a folder with one of the operations that you export! For me this meant that all polling operations were exported and imported, thus changing all their values from PRD to TEST values.
Scripted Operations are handled the same way that normal operations are handled. If you put all your scripted operations in 1 directory and in your IC you use 1 scripted operation, all scripted operations (and all operations used there in + all operations in the same folder as one of those operations) will be exported.

I hope it’s a bit clear, it basically is a cascade of relationships

If you have any questions, try to ask, maybe I can help (or I’ll point you to Mark

Hello again!

Based on this problem, I have a question for you all. The findings in this topic make it a hard job to find a good way to sort your operations and integration folders etc.

On one hand we want to eliminate the problem described in this thread. We don’t want that exporting a certain integration influences other integrations drastically.
On the other hand, we want a base for code reuseability. What is the point of Naming Conventions etc. if you can’t reuse your older operations. Besides, I think XPI/wM will grow VERY large if you build new operations for every new integration.

How do you guys sort your integrations and operations? Are you trying to implement code reuseablity and if so: how?

Thanks in advance!