We are trying to create a utility service to create consumer/provider web service endpoint alias.
We have service like wm.server.ws:addConsumerEndpoint to add the endpoint and similarly we have delete service. Can we use same add service for updating the alias.
Also, generally we use API calls from admin swagger like https://localhost:5555/admin/port/https/DefaultSecure/resourceaccess to do any admin related tasks.
Could you please confirm if we have similar API for adding/updating endpoints. I checked the swagger file but didn’t find anything for this.
Not sure what you are trying to achieve by doing that, there might be better ways to do it such as implementing a generic rest resource, getting the signature as parameter and parsing it accordingly. This way you create it once and configure ACLs properly, and you have the maximum control over the service
What you are trying to do is certainly doable since everything in Integration Server is a web service. So when you implement a service using designer, it calls IS services to create the service in the back ground. But what you are trying to implement doesn’t make sense to me and it certainly sounds like an over engineering. If you provide your requirements we can recommend a better solution.
Create a rest API linked with main service and main service invoking the service you have created “flow service by invoking WmRoot service”. Like API for a wrapper sevice and wrapper service invokes your " developed service".
Or you can directly create a rest API around " developed service"
Invoking WmRoot services manually is not recommended. You won’t find a documentation for most of the WmRoot services and SoftwareAG can make changes to those services without informing anybody.
This doesn’t sound like a requirement, rather it sounds like your (attempted) solution to the problem. Why not create a rest resource, get service signature(path) as parameter, invoke whatever you want using that path? You could be disabling a lot of validation just by creating the service on the fly. What if something goes wrong on the prod? What if it can’t create? What if you try to create a second service with the same signature? What if you delete a wrong service?
By definition, an Admin has right to do everything, but you can instead, create a separate group, and restrict the access to that group using ACL configurations. There should be a ReadOnlyAdmin group already defined in IS, you can use that and modify as you wish. Restricting access of the administrator is not a good idea anyway(you may need that page in the future). But having a separate light admin group is OK.
I agree that is OK but I would recommend against it. The gauge I would use here – what is the perceived benefit and does it offset the effort/support of maintaining such a configuration. How much time will be spent figuring out why someone has (or does not have) access to something they shouldn’t (or should) vs. keeping the out-of-box intent that the IS Administrator is for administrators, not “pseudo-administrators.”
Maintaining is not that difficult. An AD group can be assigned to ReadOnlyAdmin group and it is predefined. I can list multiple use cases for Devs needing to view some server configurations, and they can’t have admin access sometimes because of legal requirements. The most basic scenario I can think of right now is to gain speed while validation errors for production issues, like verifying triggers, DB connections, heap and CPU times before going in to detail. I agree that there are other ways to accomplish that, but sometimes cross functional teams slow down so much so that it takes multiple times longer to diagnose problems.
Definitely a YMMV item (your mileage may vary, a colloquialism as a disclaimer that results/satisfaction level might be different for every person – for the international audience here )
I created a rest wrapper service and its working fine for adding and deleting the webservice endpoint aliases. But there is no such service to update an existing alias. Could you please suggest anyway to update the existing service.
If my memory is correct, updating an existing alias means deleting it first and creating again, but I might be wrong. And since you are trying to update admin pages/services, its highly likely that you are updating WmRoot services, which is wrong in several levels and its probably not allowed to be changed by Devs anyway. You might cause a huge problem.
Using ReadOnlyAdmin group or creating a light admin group doesn’t work for you? You are definitely over-engineering! I strongly recommend you all to reconsider your approach to the problem. You can limit/grant access to any page in Admin UI if you us ACL configurations properly.
Thank you for information, we are not updating WmRoot services.
We are just invoking those services in our wrapper service to add a new endpoint.
Our requirement is not to do anything manually on IS page, we invoking the addConsumerEndpoint service we are able to add on IS page with all the input values.
Invoking WmRoot services manually can be problematic as well. SAG can change them whenever they want, and they usually don’t provide documentation for them so you might cause a security vulnerability or inconsistent behavior somewhere.
I always wonder about such “requirements” (which are usually design choices rather than “must do this”) because the item of concern needs to be defined manually by someone somewhere – my question is usually, why is manually editing a text file or other item somewhere else considered “better”? I suppose the motivation is to perform and administrative function (manage WS aliases) by people without access to IS Administrator.
My question here is how often do you really add, update, delete WS endpoint aliases? Does the benefit of programmatic changes to those offset the effort to establish and maintain/support that automation? Perhaps. Would a request from a dev to an admin equally address the need? The main intent here is to raise the item for your consideration – does this automation add value? Or will it be a source of ongoing troubleshooting/support?
Automation is a common requirements these days and in my view has a lot of advantages over doing things manually. The biggest one, on a somewhat technical level, is that a text file has the tremendous advantage of being “versionable”.
Of course you can do things manually as well. And if the organization, i.e. the people, are well trained, organized etc. this can work well. My experience, however, is that it usually does not. So for me it depends on the context whether or not manual changes are an alternative or not.
I guess this is also a bit of a philosophical topic
Yes, definitely in the realm of “guiding principles.”
“Requirements” implies “must have.” Most things presented as requirements are actually design decisions.
Yes, automation can have many advantages. But if one struggles with identifying a specific and concrete benefit (not saying that’s the case here) then it calls the automation into question. I’m an advocate for automation when it provides a specific value. I’m less enthused about automation for automation’s sake.
Versioning a text file is obviously core to the vast majority of SLDC activity. But in this case, is there a text file? Can be but presumably it would be for a single alias. The need to version an alias seems highly dubious to me. One might suggest versioning the complete list of aliases – e.g. version the file where IS stores the WS aliases. Might make sense too but that introduces other risks – deployed the latest version, which mistakenly left out an alias that had nothing to do with the current change. Or someone forgot variable substitution and the deployed alias is wrong . Something that wasn’t necessarily in scope of the change is broken.
At some point, it is manually done. Editing a text file is manual. Or editing a config in a UI console to define the alias is manual. I’ve seen many cases where the “elimination” of manual effort is actually just moving the manual action somewhere else.
Absolutely agree that context is important. Manual changes are always an option – it’s a matter of weighing the pros and cons.
My intent here is to highlight the need to view automating things with a critical eye. Make sure it makes sense. Automating something is not always the most advantageous option. “Automation good” and “manual bad” is not always accurate.
Just like premature performance tuning, I am against most of the common automation methodologies for this reason. In my opinion any built-in, out of the box solution should be preferred. Most of the common automations are implemented due to lack of knowledge of the product. Even consultants can have an insufficient knowledge on the product sometimes. I have seen a custom implemented AdminUIs for similar reasons(and this topic is oddly similar). The developer doesn’t know how to limit access to a certain page but knows some front-end development, so deletes some of the pages and creates a new admin UI. Instead the proper solution would be limiting the access of the related pages/web services. In other words, If the only tool you have is a hammer, you tend to see every problem as a nail.
)