Good morning guys!!!

Can anybody tell me how we can migrate the JDBC/Oracle Applications Adapters Connections from DEV instance to TEST instance in webMethods. Is there anyway like zipping all the packages from DEV instance using WM Administrator and migrating the files to different instance like TEST.

Can anybody tell me how to do this?

Thanks in advance and have a nice weekend guys!!!
Priyatham Porika

Priyatham,

Easiest way of doing this is using Deployer.

ramesh.

Hi Ramesh,

Thank you for getting back to me. I am not a expert in WM but trying to learn lots everyday. I know that we can archive the packages but can you please tell me the steps to migrate the JDBC / Oracle Applications Adapters from Developer?

Thank you,
Priyatham

Priyatham,

use package replication, from the webMethods Server Administrator on the development servers, select Publishing from the Package menu to
access the Create Release screen. Use the Create Release screen to create distributable releases of the packages that contain the items that you want to move. Then publish the releases to the production servers. On the production servers, install the inbound
packages.
hope this helps.

ramesh.

Hi porika, tell me one thing do you just wanna migrate the adapters because if that the case you might wanna use the deployer because publishing the package will overwrite the code you have on the target server, But with the deployer you can deploy just one adapter or one flow service. The other advantage of using the deployer is it will let you know about all the dependencies that adapter or package have.
Hope this help.

I agree with Taz, deployer will be the best option to migrate your packages and adapter connections from dev to test. webMethods Deployer lets you build deployable packages that contain and IS package as well as many server configuration settings such as users, ACLs, ports and JDBC Adapter connections.

More info on Deployer can be found in the Bookshelf section of Advantage.

HTH,
L

Actually, I’d offer that the best way to move connections from one environment to another is to not do it. Rather, it is usually better to define the connections using Administrator in each environment. Why? Because the connection parameters in each are usually different (dev IS connects to dev DB, test IS connects to test DB, etc.).

When migrating the package containing the connection, the connection parameters will obviously follow. Thus, you’ll have test IS pointing to dev DB until you go change the connection settings. Potentially worse, you’ll have prod IS pointing to test DB, which can be very bad if even for a few minutes.

Good practices:

• Place connections in their own packages. To facilitate migration of adapter services, never put adapter services in the same package as the connection.

• Never migrate packages containing connections. Define them manually as needed in each environment.

I completely agree with Rob’s point.

Ramesh/Taz/Leon Lewis/Rob Eamon,

Thank you very much for your inputs. Knowing all of your views was really nice.

Have a nice weekend!!!
Thx,
Priyatham

I would like to know why we can not change the connection parameters when using Deployer. There is an option under MAP to Configure your connection to the target server. I have tried this and dose not work properly for me. Do you know if it’s a bug?

Yes I agree with you, we use the configure button always when we migrate connections.

Migration of connections is done because sometimes we may increase pool connection settings, to make sure all are in sync we use Deployer.

Is there anyway to automate this process? Instead of manually having to alter the connection settings when migrating from a dev to test environment? What is the best way to do this?

Thanks

You can use Deployer to automate it. Other than that, you could probably come up with some scripts to automate it but IMO it is usually just as easy to manually define the connections (not migrate them, create them from scratch in each new environment).

OK thanks. Im not sure if we are using deployer in this environment, but may revert to just updating the connections manually.

I just thought I would see if there was a quick/easy solution.

Are you sure you understand the caveats presented in this thread concerning migration of connections? I just want to make sure you don’t introduce problems during migration because test data from one connection gets processed as production data because the connection is pointing (temporarily) to a test database. Migrating packages containing connections (other than when using Deployer) is a bad practice.