Hi,

Are WM have service for change URL alias, or must change from admin page?

Regards,
Momon

@dekaa,

There is updateAlias Service in WmRoot to update URL Alias as below.

wm.server.httpUrlAlias:updateAlias

But its good practices to update the URL Alias from the Admin UI. let me know what is your use-case here and your need is to update this in Production environment ?

Regards,
Dinesh

Thanks for your answer @DINESH_J , For Alias ​​update from Admin UI have many steps for change, so if any service to update alias can cut some steps.

But if best practice to update Alias is better using Admin UI, I still Use Admin UI.

Is there any Problem if we use wm.server.httpUrlAlias:updateAlias for updating the URL Alias?

Regards,
Momon

WmRoot Package will be hided default and due to the security reason. This package provides certain service which could affect the environment. And also you should know what exactly you doing when you want to execute those services.

if you think by executing these service will bring you value and time saving from certain task then no issue.

Note : WmRoot Package service handle with care.

WmRoot Package will be hided default and due to the security reason. This package provides certain service which could affect the environment. And also you should know what exactly you doing when you want to execute those services.

if you think by executing these service will bring you value to your project and time saving from certain task then no issue.

Note : WmRoot Package service handle with care.

Adding to Dinesh’s comments; usage of WmRoot is not officially supported and accompanies a risk (i.e., you are on your own). In addition, WmRoot services are not documented and their functionality/behavior can be changed or services removed without notice.

Having said that, these services are incredibly handy when building custom/special solutions and I’ve rarely had problems.

P.S - The package will be visible after changing the Extended Setting “watt.server.ns. hideWmRoot” to “false” and refreshing Designer.

KM

Starting 10.7, Integration Server has a support of REST Admin APIs. Please use Admin APIs instead of root services. You can get list of Admin APIs from http://localhost:5555/admin/swagger/integrationServer or there is a doc under \WmAdmin\resources describing these APIs.

Regards,
-Kalpesh

Interesting fact… Thanks Kalpesh for this valuable resource info (useful and handy).

Cheers!
RMG

This is definitely a plus if one has a desire/need to programmatically control these config settings. Auto-deployments, info gathering tools, etc.

Once I get to see it and poke around it will be interesting if services can be called directly as internal services, instead of via HTTP. For remote calls, HTTP is a great approach (as opposed to pub.remote:invoke) but for local work, less so.

The earlier caveat about programmatically updating a URL alias still applies – are you sure that doing so provides value?

Admin API is introduced in the product based on requirements coming in from multiple customers. Customers wanted REST based APIs that is supported by Integration Server for performing any operations that Administrator can perform using Admin UI.

@Kalpesh_Shah1 Most certainly. My post was not intended to infer such a facility did not have value. It is a good addition.

For many, although I do not fall into this camp, the desire to store various settings “somewhere else” and run scripts to push them to various server targets is strong. There are pros and cons to this approach as well as the approach to manually update things via the IS Administrator UI when needed.

My main point was that one should make sure that using the API (or services in WmRoot) provide real value for the environment. Sometimes it will, sometimes it won’t. Too many times people chase “automation” as an end goal in and of itself – “It’s automated!” Without any regard to the possibility that managing the automation components might actually take more effort or cause more issues than just using IS Administrator (or Deployer or whatever). Tripping over dollars to save dimes. Not always, of course. There are times when this approach is quite useful. Just should not assume that it is.

“Many steps” seems inaccurate. It is a couple of clicks. How often do you anticipate this being changed? If it changes often, something seems off.

Using WmRoot is to be avoided but does come in handy at times. I’m not sure this is one of those times. But perhaps you can elaborate on the scenario where using IS Administrator is problematic.

changes don’t happen often, I can’t access the production server, so when I need to change an alias I just create a postman collection if there is a service to change it

Hi @dekaa_momon ,
Can you please clarify what you mean by cannot access the production server, if you don’t have the permissions(due to authorization or ACL reasons), the WmRoot services or the admin API wont help you either.

Hi @Nagendra_Prasad ,

I’m in the development and solutions division, have no access to production server.
So besides sharing how to use Admin UI, it’s easier if you can prepare a postman collection, so the operations team can just run it.

I’m sorry if my statement confused you

Whether that is easier or not is debatable. It’s mostly just different.

If you associate the alias with the package it references, there should be no need to make changes to it in IS Administrator other than in dev. It should change when the updated package is deployed. I’ve never changed a URL Alias (though we use them a bit) so I’m not certain on this, This behavior would need to be confirmed.