Changes to packages on dev server can update packages on local server but changes to packages on local server shall not effect dev server packages. How to accomplish that?


I have one IS instance one running on port 5555 and one running on 8080.
I can access both at the same time.


Default is running on 5555
DEV is running on 8080

Now here is the situation
When I make any changes to packages in dev server which is 8080. The changes also reflect on default 5555 and vice versa.

What I am trying to accomplish is when I make changes to DEV packages it should reflect changes on default package but when I make changes on default or local packages, it shall not reflect same packages in DEV server. Sort of only one way street.
DEV changes to default/local is fine but default/local changes to DEV is no no.

Anyone knows how can I accomplish this please?
Would really appreciate the assist.


I’m a tad confused here, because you just have 2 ports to the same IS instance, and not 2 different instances. If it’s just a single IS but with 2 ports through which you connect, then you cannot achieve this as you are operating on the SAME codebase/package/instance, just via different ports.

What’s your business case/reasoning for what you’re trying to achieve?



So I was able to create another instance of IS.
Now I have two. One DEFAULT and one DEV instance.



Here is the situation:
Default is one instance and Dev is one instance. Two separate instances.
In Dev and Default I have one package with same name BRANCH.
Now situation is when I make changes in BRANCH package in dev instance it SHALL reflect changes in BRANCH package in default instance.
However when I make changes in BRANCH package in default instance it SHALL NOT reflect changes in BRANCH package in dev instance.
One way street from dev to default only.
Any clue?


From what I understand , this appears to be a file syncing mechanism at the core of the problem. I’m not aware if Designer has such a feature and would leave it to experts to confirm.

The source is your DEV instance which you then want to sync automatically with the Default instance , Default instance is the target which is more of a playground to experiment with flows.

Please provide more details on the usecase, that will lead to clearer answers.


1 Like

I cant be anymore precise than that.
If that’s the case.
Then I will go with the manual approach.
Something like this using batch script
xcopy /s C:\SoftwareAG\IntegrationServer\instances\IS_dev\packages\BRANCH C:\SoftwareAG\IntegrationServer\instances\default\packages\BRANCH /y
and then reload package

So you need to find a way to automatically sync package changes from one environment to another and reload the package when the sync happens, I would wait to see if someone has any thoughts on how this can be done.

Copying and replacing low-level artefacts (such as folders, flow.xml, etc.) in the back, even though it usually works, is not recommended (and unsupported). You will run into complications with, for example, Java services and referenced artefacts.

Deployer and beyond - You can consider a CI/CD setup - explore webMethods Deployer and the CLI options it offers first, then go from there to a repository like GIT and then to ABE, Jenkins and beyond. There may be licensing restrictions and a lot of work involved.

wMUsers - Alternatively, you can look at a public util package called wMUsers, which can export the packages (if I’m not mistaken, it exports the entire set of packages on your IS and not specific ones). You then take those packages and deploy on the target instance - you can automate this with some effort.

Admin API - If you cannot find the wMUsers package on the internet, then use the Admin API operation (POST /admin/package/{packageName}) that has an “archive” function for the package. I haven’t tested this, which is why I have mentioned wMUsers which is an outdated util.

Note - Remember that folks like @Nagendra_Prasad and others spend their personal time to help out on the forums. A lot of the times, they have to research and reproduce the issues on their environments, to provide a helpful answer, again in their personal time. We must exercise patience in discussions. I uphold Nagendra’s request for a use-case, i.e., the purpose or the why behind what you’re trying to achieve, whereas you’ve only explained what you’re trying to achieve.



As long as the third party tools are considered. I am not looking at outside options.
I want to utilize something that webemthods has to offer.
I will research into webmethods deployer and also wmusers.

You folks keep emphasizing on a use-case.
So I was pondering upon that.
Here is the simplest way to set it:

I have two instances running. I want to link them both first.
Then any similar packages within both instances, I want to link them as well.
Parent instance will always be DEV and secondary is default or you can use local as well.
So the final motive is whenever Parent instance package has any changes done. default or local instance package shall acquire it. One way only not vice versa.

I hope it clears the blur a tad.


I also found inbound/outboud/relicate/recovery of zip folder.
But these are all manual ways.
Linking two server instances and automatic sync on similar packages doesn’t seem to be an option.
On Manual approach there are tons of options but that defeats the purpose.

Just one more question:

Is there a reason why you have both instances locally on your machine?
Usually each Developer would have its own default instance and when the changes are finalized they should be merged/deployed to a central shared DEV instance for integration testing. From there the code can be propagated to QA and Prod Environment.


You are absolutely correct.
what I showed is an example on my personal laptop setup.
I cant show my work stuff plus I already have that setup made available for me.
The only problem is every time there are changes in dev. I manually have to take those changes and add that in local. I just want dev and local to be synced and whenever changes occurs in dev it should automatically update local.
I cant able to figure that out, how this can be accomplish in webmethods using webmethods internal features/functionality.

There are solutions to periodically sync/ sync on demand packages in two different Integration Servers in addition to those as Kasi as highlighted earlier , you can also check the publishing feature available in IS Admin UI through Packages->Publishing , where you first register a subscriber , create a release (package version) from source , Send the release to the target IS.

You have probably considered this already but Automatic syncing does have its share of problems, if the source package which is being modified has some incorrect changes , then those changes will be automatically propagated to another environment as well. Hence you may want to choose when to sync.

Hope this helps,

1 Like


Which version are you running on?

At least from 9.12 onwards there is a diff functionality in Designer which also allows for syncing code from one instance to another.

Just right click on the package in the source server and then select “diff with other” and choose the target which should receive the changes.
Then you can introspect the differences and choose in which direction they should be synced.
Please note that this does not apply to all node types available in Designer, i.e. AdapterConnections, AdapterListeners.
Even AdapterListenerNotifcations and AdapterServices might be a little bit tricky here.
But for regular services and doc types this should be working quite well.


Crosvista is the answer to the riddle.
I will do my research and provide a solution in this thread so others wont go through the hell that I had to go through.

Thanks everyone.

Hi @Sufian100 ,
From what I could find this appears like a partner product - CrossVista Team Server for webMethods: Scriptless DevOps , so there might be some additional cost involved.
Also there are some discussions about CrossVista in some old threads(most over >5yrs old) Search results for ‘crossvista’ - Software AG Tech Community & Forums , I wasn’t aware of this product , so thanks for sharing.


1 Like

I had missed that thread, sorry.

From what I understand so far, I would usually recommend to use a VCS. Is there a specific reason for not doing so?

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.