UI powered by Material Design for Bootstrap (MDB):

WLST.pλ is a "word play". It's all about WLST, Python and λ.
On the other hand, the "Well Known Attributes (WKA)" is also a "word play" based on the Well Known Addresses (WKA) feature - however it has nothing to do with this feature.
Basically this tool is a YAWDGT - YET ANOTHER Oracle WebLogic Server (WLS) DATA GATHERING TOOL.
GitHub
- If you want to skip the background story then go on GitHub to download and run it: WKA_WLST.pλ
Abbreviation:
1. The WLST story - BPM: Oracle Business Process Management
- FMW: Oracle Fusion Middleware
- MBeans: The WebLogic Server® MBeans
- SOA: Oracle SOA Suite
- WLS: Oracle WebLogic Server
- WLST: WebLogic Scripting Tool
This tool and blog post are targeting Administrators and/or Developers already familiar with WLS and WLST. In order to understand the verbiage / tech lingo of this blog post, you should have previously installed & configured WLS and have become familiar with WLST.
The main goal of this tool is for you to have a 360-degree overview of some of the main WLS resources (Attributes) from your domain. The focus is on WLS related resources no matter the FMW domain nature; it could be a simple WLS one, a SOA-BPM one or whatever is powered in the background by WLST.
The idea with this tool is very simple: for you to have a better understanding of the WLS domain and also - when necessary - to share this info with others.
No more questions like "what is the default value for this Attribute ?". No matter if a custom or the default value is in use: it will be printed/listed in clear text!
Let's say you want to share some info [e.g. troubleshooting advice] from your domain but you don't want to give remote access to your domain. Then you will run a script and send the output to others. Also, why not provide them with a nice HTML-based output ?
For sure this idea is nothing new; actually I ended up creating this tool based on this blog and Daniel's brilliant idea: "Get an Offline or Online WebLogic Domain Summary Using WLST!"... The blog post is from 2013, my idea and dream (plus some silly tests) from some years ago, but only recently I found the time to create this tool.
The idea is simple: run the WLST and print() all the output to an HTML file, then add some CSS and JavaScript and you have a better alternative than the terminal. Also, keep the resources needed for the tool to run to a minimum: you want for others to run it as quickly as possible and not force them with 100 steps or to install some extra products; no need to shave a Yak before running this tool.
wlst:
wlst:
Above each table you will find the specific WLST location-path used:
The 2 main root locations used are domainConfig or domainRuntime and from here different MBeans were selected.
If you need to better understand your own domain, you can browse WLST to the same locations per the UI sections - the only difference is the fact that the UI will not include the custom resources [e.g server name, domain name or data source name] in the path.
2. The Python story
For this tool I used Python. It's actually the built-in Jython that runs under the WLST but I "ignored" all the "J" specific features and I only focused on Python.
I like to see WLST as the "Schrödinger's scripting tool" since it's both Java and Python but unless you actually start working with it (on a more complex level) you don't know the type of errors/issues you need to handle: Java or Python.
Speaking of how much you can ignore the "J": you will see some text with an odd pattern like "java.lang.String[text here]"; however this is how WLST itself prints the data:
Oh, the irony!
Oh, the irony!
Hello lambda functions; Python lambda that is! The tool has some lambda functions but this is not the full reason for the "λ" in the title...other than the fact that it looks like a reversed "y".
"λ" stands for the Greek letter "L" ... Well, duh!
The main features of this tool are:
- λight. It's a very light tool. Both the source code and the output is very light. For a simple WLS domain the output is only ~400kB. Not even 1MB, but still full of information/details. The main reason is very simple: no "λogs" are gathered. Of course the logs are very important [e.g. when troubleshooting] but you can ship them archived separately from other type of configuration output that covers the domain.
- λs() or the list function. Very much like Linux: list me whatever you have in the current location. WLST has the same function and the same approach. The idea is simple: just list me whatever the info (Attribute - Value) from a specific MBean and no need for me to try and do some hard-coding. This will give me some flexibility (since sometimes different details could be found in the same location based on the WLS release or the FMW product) and later I only need to take care about the output (data structures) and how to handle the output. Since (some of) the MBeans have 1 ton of attributes/parameters then the output can be big and this will translate into long HTML tables - this is why some CSS or JS (e.g. a search option) should be applied for the UI to be more user-friendly. Do keep in mind that here the focus is on the WLST output and not the UI; this is not a web site!
4. Will it run on my OS?
The tool can be used on all types of OS....if the WLST [aka the WLS/FMW product] runs on that specific OS you use; if you can start the servers then this tool will also run.
Once the connection to the WLS domain is established then is all about the default WLST!
For the OS-related details (e.g. OS full version, host name, CPU, free space, memory) a different approach was used: a 100% Python3-based script; however I think that in the future a distinct UI output should be used for the OS info- at the end this WSLT tool should only reflect and focus on the WLST-related info. This is why only some main OS-related details were included: to have a big picture on the OS.
For the OS-related details (e.g. OS full version, host name, CPU, free space, memory) a different approach was used: a 100% Python3-based script; however I think that in the future a distinct UI output should be used for the OS info- at the end this WSLT tool should only reflect and focus on the WLST-related info. This is why only some main OS-related details were included: to have a big picture on the OS.
You will find an .sh file (for Linux) and a .cmd file (for Windows) that will trigger both the WLST-related scripts as the OS-related scripts.
In case you ask: I don't have all the "*nix" OS flavors on my laptop so the tests were done only on a Linux (Mint that is).
In case you ask: I don't have all the "*nix" OS flavors on my laptop so the tests were done only on a Linux (Mint that is).
In case of issues, for now, you will need to remove (from the sh/cmd file) the call to the OS-related script and also to copy-paste the last HTML rows from the OS-specific UI script to the HTML output file. However, I see no reason for this step since it should work with no issues by default.
For Linux, you will notice on the terminal some warnings: some OS data was not gathered; this is because root privileges are needed to collect that specific data. Just ignore those rows and never use the root user for this tool!
5. The Errors, Warnings and Issues story
5.1 "No such Attribute"
One of the reasons why the ls() function and not the get() is used: believe it or not but not all the related WLS resources have the same attributes! You will see this in the HTML output as a nice icon with title "No such Attribute":
This is not an error/warning! It just prints the fact that a resource has no such attribute so there will be no value for the specific resource - even if other related resources have this attribute and a specific value.
If you still don't fully understand this idea then go to your WLST terminal and inspect 2 or 3 different servers and write down the attributes and later compare them; all the servers will list the same 98% attributes but for the extra 2% you will see there are differences between the WLS servers. So less error handling, less hard-coding and handle all this within the Python code.
5.2 "No such resource found in the domain."
The "No such resource found in the domain" will be printed when.... no specific resource is found for the specific domain. The resource is not visible.
Let’s assume you just created a simple basic WLS domain and you run the tool and for the Data Sources-related sections you only see the above message. This makes sense as within a fresh new basic WLS domain there are no default Data Sources created, so the above message will be printed only when there are no Data Sources defined in the domain. The alternative is for the tool to stop with an error :)
Where possible, the text will print the custom name of the resource not found or just a generic message, but in the end the same idea is printed.
From time to time you will see a more complex and probably a less clear text:
The idea is very simple: there was some type of error or issues found and this message will try to catch whatever the issues were. For now this is an umbrella for different issues:
- "upgrade to the latest FMW release"
The above MBean "NodeManagerRuntimes" is a good example since you will not find this MBean for some older WLS releases; based on my tests I think this MBean is only available starting with WLS 12c. This is the reason why the message will ask you to "upgrade to the latest FMW release". The tool covers both 11g and 12c releases but some MBeans are only available starting with 12c.
Link the above idea with the "The MBean is not part of the domain" message.
- "Review the MBean name/path"
For the current MBeans included in this tool you should find no issues with the name or the path used. At the end this is why I did my tests: to make sure there are no issues. However, if you want to update the tool with your own MBeans and you will do some mistakes with the path used, based on the functions provided, then there is no reason for the tool to stop with an error.
6. Disclaimer
- I don't own production environments - and, no matter what, tests should be done on test environments.
- I don't own complex environments on my laptop; the best case was an Oracle XE database on a Docker container as the RCU database.
- Even if I did my tests you should also start with a test of this tool on a more mature "test" environment and only when comfortable enough to move to real production.
- I focused my tests to make sure that scrips run with no issues and that the details printed are relevant. However, I never checked the performance and what impact the tool has on the machine or the domain itself.
- The OS-related Python3 scripts have no impact on performance: they move so fast that you don't even have time to blink.
7. NO Passwords collected
The tool will only print the already WLST built-in pattern for the passwords: "******".
This is how the ls() function will print the password-attribute's value.
The scripts are mostly based on ls() basic WLST functions and the WLST will list no passwords in clear text; on the other hand the get() function for a password will print you an error - this is why the ls() was used as the main WLST function.
As a summary: no passwords are collected/saved. Not even when you need to provide the connection credentials: the value typed in for password will not be echoed back to the console.
8. ONLINE & REMOTE options
For this release, you need to connect to the Admin Server and also to provide the Admin Server credentials; the tool connects to a running domain.
I like my domain and the Admin Server up and running.
You can also point the tool to a remote domain; it's the basic WLST "connect" function: connect('weblogic','welcome1','t3://localhost:7001') - just change the URL:port to a remote Admin instance and that is all. The tool will use the local WLST binaries but the data will be gathered from the remote domain.
However, always the best is to run this tool from the specific Admin Server machine: less time for the data to be sent and printed on the output HTML file. In addition, the OS-related scripts will be able to gather OS data from the Admin Server machine.
If using a Docker container: move the files to the specific volume.
9. Design Principles
The WKA WLST.pλ tool was created based on the below main design principles:
1. Should not replace the Admin Console. At the end the Admin Console is already complex and a valuable tool.
2. The tool is not a new Admin Console - it does not reinvent the wheel.
3. The tool should bring under the same umbrella all the resources that have the same pattern or are found in the same WLST location.
4. The tool should keep the UI -as much as possible- separate from the WLST/OS code; functions are to be used and the UI should call the functions per specific arguments.
5. Since logs are heavy and could be shared as they are, the tool should not gather them. Keep the output as light as possible.
10. DEMO
On GitHub you will find a demo HTML output per each OS. The idea is to see how the output should look like before running the tool- some of the data (e.g. on the OS tables) might not be relevant since it was replaced with dummy data.
Exactly: 1 basic HTML file generated per each OS is all the output you need.
Exactly: 1 basic HTML file generated per each OS is all the output you need.
11. Material Design for Bootstrap (MDB)
Most of the UI specific design is found inside the "_UI" files. However, some of the HTML design details are also included in the WLST and OS related Python functions.
Why MDB?
In the past I was using the Bootstrap library; later I also found the Material Design but I had a dream to find a mix between them. For me this is what MDB is all about.
In addition to this valuable mix, the MDB documentation is easy to follow, you find tutorials to cover your needs and you will have very fast the UI you dream about.
Note: I do have to say I'm not an expert on MDB so feel free to make your own updates to the UI; I know that some tables are huge - the more complex your WLS environment is the more you will need to scroll to the right-side :D
Don't forget the "Search" option and the fact that you can export to Excel.
It's such an art to have the perfect UI: you test a 5px value and it looks horrible but a 5.5px value will do the trick. To test an UI is like a never-ending story: you always find something to update since new ideas always pop in.
12. Copyright & License Why MDB?
In the past I was using the Bootstrap library; later I also found the Material Design but I had a dream to find a mix between them. For me this is what MDB is all about.
In addition to this valuable mix, the MDB documentation is easy to follow, you find tutorials to cover your needs and you will have very fast the UI you dream about.
Note: I do have to say I'm not an expert on MDB so feel free to make your own updates to the UI; I know that some tables are huge - the more complex your WLS environment is the more you will need to scroll to the right-side :D
Don't forget the "Search" option and the fact that you can export to Excel.
It's such an art to have the perfect UI: you test a 5px value and it looks horrible but a 5.5px value will do the trick. To test an UI is like a never-ending story: you always find something to update since new ideas always pop in.
This is a free of charge tool. The main purpose was to have some fun with Python on my spare time. Even if the collected data is from an Oracle product environment still the focus is on Python (mostly lists and dictionaries).
In addition to the Python, my aim was also to play with the MDB framework.
- Since the current tool has the UI based on MDB, unless you fully change the UI with your own alternative you are not allowed to remove the MDB icon from the footer.
- Unless you use your own alternative, the custom CSS and the custom Java Script details should not be obfuscated in the generated output HTML file.
- Unless you replace the current Java Script rows with your own, you should not remove the Java Script comments in the generated output HTML file.
- You should not remove the license from the Python scripts; however, if needed, you can add your own text on top of the current one.
13. Dark & Light UI
Don't forget that you can switch between the dark mode and the light mode from the menu right side of the UI; by default you will see the dark mode.
14. Credits
Different resources were used to build the UI:
Some of the UI resources are CDN-based.
I will add here, again, the fact that "Get an Offline or Online WebLogic Domain Summary Using WLST!" blog post inspired me.
I will add here, again, the fact that "Get an Offline or Online WebLogic Domain Summary Using WLST!" blog post inspired me.
Pic source: