I have recently installed webMethods Integration 10.11 free trial. I am currently in process of exploring & learning this suite.
I would like to know where or how can I come to know about the rights each pre-defined role has in webMethods?
I am asking it because I need to know what rights each pre defined user role has in webMethdos so that I can assign correct role accordingly.
For example, a user assigned with “Developer” role can’t see server logs in webMethods UI. Now if I want to allow that developer, the access to server logs then I first need to know which role(s) have access to sever logs? and then I can try to assign some other appropriate role to that developer user so that we can view server logs also as he needs to view/check the messages he is writing using built-in debugLog service.
I tried to check SAG documentation but couldn’t get list of rights for existing roles.
Please guide me where can I get details of rights for each pre-defined user role in webMethods integration.
Major services in Integration server are protected with Administrator or developer rights. These are the major roles in IS.
To view the server logs or access the Administrator UI, user need to belong to Administrator group.
To access Public services, developer role should suffice.
Thanks for getting back to me on this one. Is there any other role (other than Admin) that allows access to server logs?
Admin is the highest role. May be we can assign some other role (lower than Admin) to that developer user?
I am assuming you are trying to access Server logs via Integration Server Administrator UI.
As the name itself suggest, it needs administrator role to access the functionalities on the portal.
It cannot be accessed via any other role.
Thanks Sumit for your response. I understand your point
At my current project, we addressed this problem by shipping our logs to Splunk. Developers can then use all of Splunk’s capabilities to browse and query the logs there. If you have access to Splunk, Elasticsearch, or similar technology, I highly recommend this approach.
Thanks for your response. Can you please let me how you shipped logs to Splunk? Did you integrate webMethods & Splunck? I mean did you configure webMethods to write logs to Splunk? Or did you develop some mechanism to upload webMethods logs files to Splunk?
I am asking it because I am new to webMethods and don’t know much about its logging capabilities or its capacity to integrate with external logging frameworks etc.
So if you can share some high level details or high level steps you followed then it might help me understand if and how we may take advantage of it.
There are different ways to integrate with Splunk. Our approach for shipping the webMethods logs to Splunk was to install the Splunk forwarding agent on the webMethods server and then configure the agent to monitor the webMethods log files (i.e. server.log, wrapper.log, etc).
We also have a custom logging framework built on Log4Jv2 that all of our webMethods integrations use to log different events. That logging framework writes out events in JSON format to a separate log file and the Splunk forwarding agent is also configured to monitor that log file. With those events being written in JSON, our ability to query the logs in Splunk multiplied, given us the ability to build rich dashboards and alerts in Splunk as well driven directly from those log files.
Your approach/solution sounds good and makes sense.
Can we easily configure webMethods to use any third-party logging framework (for example, webMethods may start writing logs to that third party logging framework directly instead of using its own default log files)?
How did you integration webMethods with custom logger? Did you include some java code in your webMethod services to enable them to write event/information to your custom logger?
I would like to hear more about how custom/third-party logger can receive webMethods integrations or service related error/events because we also plan to integrate custom logger with webMethods.
We simply created a webMethods package that exposes services that services from other packages can call to issue log events. This package takes care of formatting the log events and enriching them with additional information where necessary. So, yes, this package does have several Java services that call the Log4J API behind the scenes.
Thanks Percio. Big help indeed.