Hello Everyone!

I have some doubts about the Deployer solution.

In my QA Integration Server environment, I created a new package with some new services projects inside of it and now I need to deploy them.

These projects are using WaJDBC Adapters Services with connections that aren’t created in production environment yet.

Using the “Deployer” solution provided in my QA Integration Server admin page, I created a new deploy project to deploy one of these projects, checking the “None” option in all options on “Suspend during deployment” section.

In “Define” area, I checked the project folders, with their services and adapters. Then, in “Unresolved Dependencies”, I checked “add” only in the new WaJDBC Connection Adapters.

Can I securely deploy a project without affecting others WaJDBC Adapters in my production environment?

I ask this because in long time ago I had the same situation with another deploy project. I checked “add” in “Unresolved Depedencies” for the newly created WaJDBC Connections, but I didn’t check ‘none’ on ‘suspend during deployment’ section.

Then, during the deployment, all of WaJDBC connections in my production were suspended and took some minutes to get connected again.

This caused a lot of trouble in my work and I wouldn’t like this to happen again.

Thank you

Hi Renan,

we are creating the connections manually on each system and only deploy the services while marking the dependencies as “Exists”. Therefore we have moved the connections to a different package which will not be deployed.

Esp. when it comes to SAP Listeners deploying Adapter Connections and Listeners becomes complicated as SAP Listeners are not supporting variable substitution during deployment.

You can also have a look at the Deployer Users Guide for further informations.

Regards,
Holger

Hi Renan,

I believe you using None for all the options will prevent any damage to components running on Production.
But it is worth trying out first on any pre-prod environment or live support environment which is an exact replica of production. With that, you will be sure of what is going to happen.

If you don’t want the adapter connections to be deployed, you can Ignore the dependencies and deploy only the new services as well.

Regards,
Firoz N

Thank you guys for your answers!

@Firoz and @Holger_von_Thomsen, I did what Firoz suggested (about pre-prod environment) and, unfortunately, no matter which deploy project property I define, it will always close all of the connections in WaJDBC Adapters package.

The only way to deploy a project to production without causing trouble is like @Holger_von_Thomsen said: Manually.

I didn’t find other way until now. I have to create the same connection name in production before deploying the service.

More for your reference - The Software AG PS PRIME Standards which were put together through years of experience with IS specify that JDBC connections should exist in a different package than implementations, i.e.

All JDBC Adapter connections should be in separate packages, that is a package should not contain connections mixed in with other assets. This aids deployment of services as this means changes to packages can be deployed without unnecessarily affecting the JDBC Adapter database connections. Recommendation is to have adapter connections in packages on their own, and not mix these types.

@Dave_Pemberton, thank you for referencing this topic.

I really would like to change to a better JDBC architecture here in my job, like the mentioned way mentioned.

But, unfortunately, I really doubt that they (you know who…) would accept it .

It’s too risky to make this change with 30+ JDBC Adapters that we have here. If only 1, just 1, fail, there would be a mess in our production environment.

Thanks for presenting this “PS PRIME Standards”. I will read more about it.

my personal opinion - I understand the reluctance, but doing this would help to reduce issues and risk caused by future changes going forward, and as the solution beds in, teams/people change, but things still require changing, these sorts of things tend to get missed/forgotten and created unexpected surprises causing production problems that become difficult to diagnose as the knowledge gets lost

You could change/move the connections one at a time as you re-deploy changes to the packages to help de-risk this.

Deploying things manually should not be acceptable, and even using deployer, you really should be considering how to wrap this up into a CI/CD tool to automate everything required to further reduce effort and risk in deployments.

Hi Renan,

first create the new package with the new connections and enable them.
You can copy them from the existing ones in the adapter UI on IS.

After that check IS Built-In-Services Reference for the WmART package/folder, there is a service called setAdapterServiceNodeConenction.
This service takes two input, the service for which the connection should be changed and the new connection node name (needs to be enable before changing to it).
The first one be copied from Designer Navigation and the other one should be copied from the adapter UI as when you run the service in Designer you can only copy one value from the navigation before running the service in Designer as “Run As Service”.

Remember to add a dependency from the package containing the adapter services to the package containint the connections to avoid access to these services before connections have been enabled during startup of server.
After changing all the services in one package, remember to reload the package with the services to activate the new connections for the services.

The switching to the new connections only need to be done once and this can the be deployed by selecting “Exists” to the connections in the separate package after this has been created on higher environments.

The old connections can then be disabled and removed from the original package after this has been completed.

Regards,
Holger

It is a great piece of note and steps by @Holger_von_Thomsen

Just one point, when you run the above service, just ensure your adapter service for which the connection node is to be modified is not locked. Also, ensure the user is having relevant permissions for that adapter service to modify it.

Regards
Firoz N

Hi,

additional information:
The same procedure described above for connections also works for listeners and notifications.
Just explore the WmART package for the appropriate services.
Remember that Listeners and Notifications need to be disabled prior changing the connection (for listeners) or listener (for notifications).

Regards,
Holger