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?
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.
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.
I understand your concern but here are a couple of points that may put your mind at ease with this approach:
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.
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.
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.
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?
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
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?
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.
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.
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.
This topic is not covered in the official webMethods Deployer User’s Guide.