Read-only access to Integration Server codebase?

,
1

My company uses on-prem SAG software. We have a team of integration ‘project managers’. These folks manage integration rollouts and often need to create specifications for custom rollouts (with requirements like “Map the buyer order reference from /x/y/z@orderID”)

I wanted to let the project managers use Software AG Designer, but with read-only access to our integration development codebase. The intent is to:

  • Improve communication between project managers and developers by sharing concepts
  • Explore B2B standard data structures, leading to more accurate specifications (e.g., navigating a cXML order document and copy/pasting its XPaths)

The problem is Software AG Designer requires users to have the ‘Administrator’ or ‘Developer’ roles – these are not read-only.

Instead of read-only access, another option would be to runup up a copy of our development IS and have a job sync codebase every night or every hour.

Thoughts and opinions? Has anyone done this in the past? There is older discussion but it’s not clear.

2

I’m not sure if this meets your requirements completely but this is what I tried.
As a user with Administrators ACL, Created a package ReadOnlySrc with a folder ReadOnlySrc, set the Write ACL on the folder to Administrators.
As a user with Developers ACL , in the designer , I can list, read and execute services in the folder, but not edit them.

-NP

1 Like
3

Hi Nagendra – thanks for replying. No, that isn’t what I need. I want to giving this new class of users access to the entire existing codebase (Wm* packages and custom packages), without modifications to packages themselves.

Maybe a clone ‘playpen’ IS is what’s needed.

4

I see, I would play around with having packages in version control and providing different classes of permissions ( read vs read/write) to users. Would wait for more responses , maybe there is a simpler way.
-NP

5

Thanks Nagendra

6

You cannot do this through Designer, nor is it necessary. Simply allow the developer to clone the source repository with a user that only has read access. That way even if any changes are made locally they cannot be committed to the source base.

Basing read/write access around the versioning system makes more sense and is easier to maintain.
regards,
John.

7

Thanks John – that’s good strategy. But one problem is we do not use version control webMethods code at my workplace. There are only two developers at my org (including me), so locking services and shared environments (DEV/UAT/PROD) have sufficed till now.

We use git for managing other code so I was trying to see if I could bootstrap git version control into our existing webMethods development environment. I just saw your pointer about package structure in this other article – I’ll respond there.

8

@Sonam_Chauhan This is definitely possible and can be achieved with a simple piece of code. Here are the steps:

  1. Create a new group called RoUsersGroup.
  2. Add your users to this group. Also add them to the Developers group.
  3. Create a new package and add a startup service to this package.
  4. The code for the startup service should look like below. This will allow these users to see the code. They can even change it, if they are using local development. But they will not be able to save it. So, the server will always have the original version.
InvokeManager.getDefault().registerProcessor(new InvokeChainProcessor() {
  public void process(Iterator chain, BaseService baseService, IData pipeline, ServiceStatus status) throws ServerException {
    String serviceName = baseService.getNSName().getFullName(); 
    if ( serviceName.equals("wm.server.ns:putNode")|| serviceName.equals("wm.server.ns:lockNode")) {
      User currentUser = InvokeState.getCurrentUser();
      if (!currentUser.isAdministrator()) {
        if (currentUser.hasMember("RoUsersGroup")) {
          throw new ServerException("User is not allowed to make changes to server nodes");
        }
      }
    }
    if (chain.hasNext()) {
      ((InvokeChainProcessor) chain.next()).process(chain, baseService, pipeline, status);
    }
  }
});

Off course, you will also need a shutdown service to remove this processor, just in case somebody reloads the package and causes multiple processors to register. Let me know if you need the actual project/package that can do this. I am not sharing it here as I use my own Designer plugin for java development and exporting that will not work without the plugin. But I can clean it up and share it.

Rupinder Singh

2 Likes
9

Thanks heaps @rupinder1 … sorry for the late response. This seems very promising… I’ll give it a try pronto!

10

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.