Iam using 10.7 deployer, is there any way that i can automate the code deployment without using ABE.

I completed all these steps (Simulate >> Checkpoint) Just Deploy step I want to automate it and get the deployment report in email. is there a way?

Or any other methods like using publishing and subscribing packages or anything else?

Deployer has APIs available that you can call from a script (which is what ABE can/does do).

When you say “automate” what will be the activity that causes it to execute? Is it a button push somewhere else?

There is a confusion (I had that too) about what ABE does. ABE doesn’t deploy your code, it deploys your assets to a repository. If you have an MSR license you can use Automatic Package Deployer, the link is below.
https://documentation.softwareag.com/webmethods/integration_server/pie10-15/webhelp/pie-webhelp/#page/pie-webhelp%2Fto-autopackagedeployment_for_packages_2.html

There is also a new tool you can use, but its really new. It may or may not support your deployment strategy.

The other manual approach is using WmDeployer from bash or as webservices like Rob mentioned.

Hi,

you might want to check for the ProjectAutomator script, which is part of the WmDeployer package.
This script should be described in the Deployer Users Guide.

Regards,
Holger

Basically, I want to schedule my code deployment final step (deploy). All the prerequisites I can complete before.

I think 1 option is to generate the project Automator file through deployer and call it through a unix script or a schedule service during the desired time.

Another one I came across: invoking this URL through a scheduled service.

http://localhost:5555/WmDeployer/deploy-list.dsp?action=deploy&projectName=AnimalPark&projectType=Runtime&deploymentName=myDeployment&preDeployString=false&force=true

http://localhost:5555/WmDeployer/progress-report.dsp?type=deployment&projectName=AnimalPark&deploymentName=myDeployment

Deployer is usually my last option to deploy my assets. May be its me, may be it really is overcomplicated, I don’t know. To me it looks like a fragile, can fail because a multiple different reasons product. It has good to have features like dependency check, but it is not trustworthy to me. In your case if you have MSR license I would use automatic package deployer.

It’s you. (honestly joking)

As with most things, people have different experiences. We use Deployer for all package deployments. We use the “Runtime” project type, which has been deprecated for debatable reasons (a separate topic I suppose). Certainly there are pros and cons, but it has been solid for us. We have never had an unexpected “what the heck happened?” with it.

Even though I didn’t like it, I also mostly used deployer. It was probably because I had a very huge package with a shared xsd schema that had kept failing during deployments. It became a trauma for me.

@Sandeep_Deepala If you’re already using Deployer this seems like a logical approach. Instead of someone pressing the deploy button, schedule it as a task. Or have a script or Jenkins or whatever do that based upon whatever “ready to go” event makes sense.

Useful documentation, I’ve been looking for it for a long time! It helps to understand some points!

If using Ant is an option, there is a project on GitHub that has custom Ant tasks for Integration Server.

I had used those since 2009 on many occasions with great results.

While probably not relevant in this context, it is also possible to “deploy” IS packages just via the file system. This is quite important when building container images.

When you simply extract the ZIP archive of the package into the packages directory (note that the ZIP does not contain the package as a sub-directory), it will be picked up by IS during startup.

Does this always work? Are there some exceptions to be careful about? Btw this and package export/import deployments are usually dangerous. It bypasses the dependency check completely. It should be complimented with after deployment sanity tests.

Be aware:

• No dependency check. If necessary services are missing on the target, you won’t know until run-time.
• No ACL assignment. If services in the package have ACLs assigned, they will not be carried to the target. Permissions are not in the package, they are in a server-wide confg file (which can make version control and deployment using tools other than Deployer a bit more fun!).

You both (@engin_arlak and @reamon ) bring up valid points. Thanks!

In practice I have always addressed the dependency part via the overall CI/CD pipeline. So, if someone had added a new dependency and forgotten about it, that would have come up in the SIT environment at the latest; although it was mostly detected in CI.

The permissions are a different story and the design to have them in only a single central place is not ideal in my opinion. In the past I had dealt with it via WxConfig, but with containers I will also look into an “offline” aproach, similar to the ART Connection Updater.

I realize that my overall approach to often develop my own tooling is not everybody’s cup of tea. But it has always worked extremely well for me for more than 15 years. And the productivity gains were significant in that it allows a completely different approach to application development wit IS.

Are there other aspects that I missed to address?

Adapter connection pools are another item of interest. Do you deploy packages that contain them?

Another item is publishable doc types. Deployer auto-sync’s them (if the project is configured to do so). If pushing packages around at the file level which contain such doc types, that would be an additional item to address.

JDBC Adapter connections are deployed if the bound package is exported. I had a support ticket recently. SAG support confirmed that export and then import packages will import JDBC adapter connections properly.

This will definitely require a manual sync. I wish there was an automatic mechanism which automatically syncs the document if it is not found in UM server.

Certainly. But the caveat here are the settings within. Copying a package from dev to test/prod will likely have environment-specific settings. And if copied and enabled, even potentially for just a short time before changes can be applied, the results can be undesired (or disastrous).

It was covered in another thread, but we never deploy adapter connection pools. They are all in one package which is never deployed. We create them in the target environments manually.

I haven’t looked but I imagine there is now something in the admin API that would support this.

Like everything else, there are services for this but it is not automatic. You need to trigger them manually.

The common practice for packages that host the adapters and the connections are different. They need to be in separate packages no matter what. For the connections you configure it once and you can keep deploying the same package during container startup, or keep it as it is if using it on prem. For adapters there should be a package dependency set properly for sure. And then there is no harm in exporting and importing the package. So the connection package will be environment dependent but the adapter package will be deployed from lower environment to upper environment.

I was thinking the call to it would be added to whatever script/tool used for deployment (or CI/CD). For deploying packages containing publishable doc types, include a step that would make the call to sync.

Right. I was referring to adapter connections. Adapter services within packages are not a concern, per se, other than the aforementioned dependency check (on adapter connections) we both noted.

Interesting discussion

Allow me to add one thought: In my opinion we need to be careful to distinguish application design (in the sense of DDD - Domain-Driven Design) and deployment. Both are of course closely inter-related, but looking at them at least kind-of independently makes things a lot easier for me.

My approach to the application design is roughly like this:

• I have several types of packages
  • Application level: The part the business sides cares about. An example in my case was syncing opportunities from the CRM system with cases in the export control system. So services would be e.g.
    • Scan CRM for new opportunities and create a new case in the export control system. The crucial point is that this package has no idea about the specifics of the CRM system; those are dealt with in a “system” package. All this package nows is that for the context of the task at hand, an opportunity is considered “new”, if it does not have a case ID assigned from the export control system. So it invokes a service sys.crm.opportunity.search with the input caseIdExportControl == null. All that is pseudo-code, but I hope you get the idea.
    • scan export control system for cases that are completed and sync back the decision to the opportunity
  • System connection level: Handle connections and specifics of external systems.
    • E.g. provide a generic search capability for opportunities in the CRM system. So this package does not know what an empty field caseIdExportControl means for the business. But it does know how to execute a query (via the aforementioned service sys.crm.opportunity.search) with a given set of criteria.
    • Usually, this package would also contain the connection to the external system. If a different specific connection is needed, that can done with run-time override.
• It is vital to have proper dependencies between packages. In my case not only for connections, but also things like the Java classloader.
• There are also additional helper/util/common packages for things like business-level auditing, configuration management, etc.

I found it made things considerable easier. Yes, I needed to come up with some custom tooling. But as you probably guessed from other statements in this forum, that is not something I shy away from.

Not sure if this makes things clearer or rather muddied the waters, to be honest. If there is sufficient interest, I can probably come up with something more concise in a blog post.

Closing on a more practical note: The ART Connection Updater can disable a connection before IS starting up, as well as adjust the connection pool settings.

My only concern using a custom tool is tool maturity. When we implement a new project there are always some edge cases that we forget to address at the beginning or forgot to implement. These kind of issues can only be resolved overtime. Taking connections apart and deploying them in a different package is usually safer imo. But containerization can make this overcomplicated unfortunately.

Having been in the same shoes, I can fully understand your concern about tool maturity. That is in my opinion one of the advantages of having them as open source. You can look at the implementation and build an informed opinion yourself.