I’m trying to create a Repository Deployment that can deploy a set of services, each one with ACLs defined for Execute ACL and List ACL. The ACLs I’m using were created in IS and contain a group of users.

The problem here is that, every time I deploy the composites, all service’s permissions are set to “Default”.

I did a little research, and by what I can tell, the link between ACLs and services are described in four files: acllist.cnf, aclwrite.cnf, aclread.cnf and aclmap_sm.cnf.

Is there anyway, using Repository Deployment, to deploy not only services, but also their permissions?

Thanks in advance!
David

Hi,

I’m having the same difficulty. I’ve tried different approach but none worked out.
Please share if you find the way to do it.

Best regards,
Bruno

Yes, there is. You just need to check-in those files into your Version Control System into a location where the Asset Build Environment can find them.

For example, when it comes to the Integration Server, in my VCS I typically have the following folders:

• is
  – config
  – packages

Inside the config folder, I check-in config files whose components I want to deploy. In your case, it would be the acl*.cnf files.

When you check-out these folders and you call the Asset Build Environment (ABE) to perform a build, you simply point ABE at the top-level folder (‘is’ in this case) via the ABE property build.source.dir and it will take care of finding the configuration and the packages for you.

You should then be able to deploy the ACL’s (and other configuration items you check in) from Deployer.

Percio

Can you explain more how to do this, I follow Demo: Continuous Integration with webMethods - YouTube and add config folder in git repo as your recommend

But it only deploy package , not success to deploy ACL to remote IS

More info:

• git folder structure

• assets
  – IS
  ----- config (all file in local IS’s config folder)
  ----- Packages
• sagdevops-ci-assets-master
  – build.xml (1.6 KB)
  – system.properties
• build.xml (1.4 KB)
• jenkinsfile
• project.properties

jenkinsfile:

pipeline {
agent any 

stages {
stage('Build'){
steps {
bat "${env.SAG_HOME}/common/lib/ant/bin/ant -DSAGHome=${env.SAG_HOME} -DSAG_CI_HOME=${env.SAG_CI_HOME} -DprojectName=${env.JOB_NAME} build"
}
}
stage('Deploy') {
steps {
bat "${env.SAG_HOME}/common/lib/ant/bin/ant -DSAGHome=${env.SAG_HOME} -DSAG_CI_HOME=${env.SAG_CI_HOME} -DprojectName=${env.JOB_NAME} deploy"
}
}

}
}

project.properties

isPackages=./assets/IS/Packages
isConfig=./assets/IS/config

C:\SoftwareAG\common\AssetBuildEnvironment\master_build file :

build.source.dir=${isProjectsDir};${isConfigDir};${bpmProjectsDir};${mwsProjectsDir};${rulesProjectsDir};${umProjectsDir}

Can you help me, it possible, can you explain with a video
thank you

Additional info:
I change in master_build/build.properties and it deploy provider setting ACL to target server , but ACL and user & group still not deploy to target server

is.acdl.config.dir=C:/SoftwareAG/IntegrationServer/instances/default/config

Thank you so much! I already tested and it worked

This approach might be working but I am not sure if it is a good one.

As the content of the ACLs might differ between source and target it is not very useful to deploy the ACLs together with the code.

I prefer to manually create the ACLs on the target and tell the Deployer during dependency checking that the ACLs do already exist.

If they exist the map will show green, if they are missing the map will show red with the information pointed out.
After the ACLs have been created, the map will recognize that upon next refresh.

Regards,
Holger

That’s right but you have to include the 4 files that I mentioned so that Deployer can identify the dependencies mismatch in the Map stage.

There is no way of getting the permissions configurations when only building packages

I will keep this in mind when we start preparing for Repository based deployments.

Currently we are using Runtime based deployments.
These work the way I have described.

Regards,
Holger

Holger,

I understand your concern but here are a couple of points that may put your mind at ease with this approach:

1. Even though you check-in the entire ACL files, during deployment you can be very selective about which ACL gets deployed. In other words, Deployer will add the new ACLs to the target, it will not replace the files on the target.

2. As I’m sure we all agree, the more similar your development environment is to your test environment and your test environment is to production, the more reliable your tests become, allowing you to find issues sooner, making them less costly, etc, etc. So, I’m of the opinion that ACL’s (along with most things) should be exactly the same across all environments. Now, of course, there should probably be more rigor around who can execute a service in production versus test or development. This, however, does not require that ACL’s be different across environments, it simply requires that the membership of those ACL’s be different. This can be easily managed by mapping ACL’s to MWS roles or groups and managing those memberships in MWS.

Having said all this, checking-in/out ACL files, as well as other configuration files, can be a bit tricky because these are either complex XML files or they are properties files that are rarely sorted. This means that when two developers make changes to the same config files, merging can be painful. Therefore, additional precautions must be taken. Some examples include: always updating your local copy prior to making a change, committing changes to these files as soon as they are made, using pessimistic locks on these files, and sorting the files prior to each commit.

Hope this helps,
Percio

Hi Percio,

we are currently using remote development and the ACLs are merely the same on the corresponding environments except for the difference that in development environment the developers are members of the ACL whereas on the other environments local/Administrators-Group is member of the ACL to enable the Deployer to aasign the ACL during deployment.

We have deferred the User Management to the MWS and assign the Roles to the ACLs.

As said already I will keep this in mind when we switch to local development and repository basd deployments.

Regards,
Holger

Hello Percio,

This is a very interesting information! I didn’t know that! I always assumed that the file would be replaced (this was just an assumption, I have not tried). And this was the reason why we didn’t cover ACL in our repository based deployment procedure. We have several modules to deploy, and would like to deploy only the ACL of the appropriate module, not the ACL for the whole server.

If I understand you correctly, the ACL provided during deployment will be merged into the target server ACL.

Could you please provide more information about what files should be checked in (and deployed) in order to achieve that?

E.g. if we have some services in the folder “my.app.services” or subfolders of that, what files should I provide to specify that all that services should have certain ACL?

Thank you!

Does this (merge, not replace) also apply to the passman storage? That would be interesting to know since those are also files which are stored onece for the entire server instance but which we would like to deploy in a modular way, i.e. so that each deployment contributes a piece to the whole picture.

When it comes to ACLs, the files you want to check in are:

acls.cnf: the actual ACL definitions
acllist.cnf: who can see
aclmap_sm.cnf: who can execute
aclread.cnf: who can read
aclwrite.cnf: who can write

The files themselves don’t get deployed. They are used as an input to the Asset Build Environment, which in turn, transforms them into files that can be consumed by Deployer. From there, Deployer can deploy specific ACLs.

A similar concept applies to passwords. You check-in the necessary password files but the files themselves don’t get deployed. ABE transforms them into something that Deployer can consume and then Deployer can deploy individual components that rely on those passwords, e.g. adapter connections, web service alias, etc. You can then also use Deployer to substitute passwords during deployment via variable substitution in the deployment maps.

The password files to be checked-in are: empw.dat, passman.cnf, and txnPassStore.dat

Good luck,
Percio

Thank you Percio for this information! Where did you get it from? I’d also like to use that source of information This topic is not covered in the official webMethods Deployer User’s Guide.

How do those files get discovered by deployer? Just by their (fixed) names and location (withing the config dir which is in the IS dir)? Or should we specify some options (telling where those files reside) when creating the deployer project, i.e. when calling projectautomator?

Thank you!

Mostly from trial and error, but I was a Software AG consultant for several years so I got to trade info with many other internal folks at Software AG, including Deployer’s R&D team. Continuous Integration/Delivery/Deployment also happened to be topics that I was pretty familiar with.

As for how Deployer finds these files, Deployer itself doesn’t. The Asset Build Environment is the one that locates the original files and then organizes them in a specific folder structure and format that Deployer can consume.

You then simply point Deployer to that top-level folder (i.e. the repository) and it is able to find and consume all files in there. You don’t have to do anything specific in the Deployer projects other than pointing them to the appropriate repository alias. The same is true when using project automator.

As for how ABE finds the original files, if I recall correctly, there are a couple of different approaches that ABE takes to find and recognize IS configuration files. As I mentioned below, the method I prefer is to have a config folder under an IS folder and then point ABE to the IS folder via the property build.source.dir.

Percio

Hi Percio

Am facing a similar kind of issue while executing the repository based deployment

when I was executing the build from the source server it was prompting me with the below information, whereas the index was already created

[exec] [ERROR] [07 Jun 2015 07:41:00,811] (RepoServerAlias.java:listComposites:351)
[exec] Error retrieving repo objects from Repo Server local_repo : Repository Index is missing. Please create the index for the Repository.

I was trying to execute repository based deployment from source server to target server, tried many ways to execute its not working out. can you assist me on this.

Regards,
Kishore

Kishore,

I recommend creating a new thread. This thread deals with a specific topic of deploying ACLs.

When you do create a new thread, please attach the full output of your ABE build.[bat|sh] script and a screenshot or listing of the files that were generated in the output folder after you ran this script. Given that Deployer is complaining that the index is missing, I’m guessing your build wasn’t successful.

Once you create the new thread, please post the link here so other folks that may be interested can be redirected to the right place.

Percio

Kishore,

Are you able to resolve your issue, could you please post the solution.
are provide the new thread if created

Thanks,
Anka

The issue still persist
Sure, i will post a new thread on this, trying with different possibilities, couldn’t succeed.

Percio ~ Build was successful and it has generated the corresponding ACDL file in the output directory.

Thanks
Kishore

Hi David,

The way we resolved this problem, although it might not be the best way is the following:

1. Create an initACL java service with the following code inside:

ACLManager.setAclGroup("full_name_of_the_service", "name_of_the_ACL");

2. Make this service a startup service.

This way every time a deployment of your package will be made to a new environment, this service will execute and set the ACL.

Hope this helps,
Vlad Turian

Hi Kishore,
You need to create repository index from Deployer Page. Goto Repository Page, Click on Repository and then create index.

Hope it resolves the issue , else post here

I’m trying to do the same but it looks weird when it comes to WebService Provider for instance.
It looks like the ExecuteACL or ReadACL do not always show in the 4 files, though Designer seem to have no problem knowing what I’ve set.

Could this be stored some place else?

Hi Julien,

there are five files where informations about ACLs are stored:

• acllist.cnf (the List-ACL)
• aclmap_sm.cnf (the Execute-ACL)
• aclread.cnf (the Read-ACL)
• acls .cnf (this contains just the ACLs and their members)
• aclwrite.cnf (the Write-ACL)

HTH.

Regards,
Holger