WLS Admin 11gR1 Lab Guide

WebLogic Server 11g Workshop

Copyright 2009, Oracle. All rights reserved. - 1 -

Lab Guide WLS Basic Setup & Admin 11gR1 Workshop

Contents

Lab Guide 1 WLS Admin 11gR1 Workshop 1 Contents 1 Lab Overview 2 Lab Pre-Requisites 2 Lab 1 – Product Installation 3 Lab 2 – Create a WebLogic Domain 9 Lab 3 – WLST 28 Lab 4 – Troubleshooting 37 Lab 5 – Monitoring 43 Lab 6 – JDeveloper and ADF 57 Appendix A – Command-Line Installation 78 Appendix B – Console Mode Domain 79



Lab Overview This course should work on any Windows machine or image that has free hard disk space and around 2G+ of RAM. If you use the image that is available with this workshop, the following directories will be used, with the Labs and Installers already in existence. If you use your own image, simply ensure that these directories are used. Please refer to the following as directories on this to be used throughout the rest of the document: <WLS_HOME> - C:\weblogic <LAB_HOME> - C:\Labs <INSTALL> - C:\Labs\Lab1_Install <DOMAIN_HOME> - C:\weblogic\user_projects\wls_domain For each lab step, pictures will follow the instruction given. Lab Pre-Requisites If you are using the VM Image that ships with this workshop, the following steps are done for you. If not, you will need to complete these steps using a base Windows image prior to starting the workshop.

Step 1 In order to complete this workshop, you should download at least the 2nd and 3rd installers from the table below. The download for WebLogic Server 11gR1 can be found on the Oracle’s download site: http://www.oracle.com/technology/software/products/ias/htdocs/wls_main.html There are multiple possibilities for installation file depending on the track you decide to take. The following table lists some of the choices: Install Type Installer File Base WebLogic – Over Network net_oepe11_wls1031.exe Base WebLogic oepe11_wls1031.exe WebLogic + JDeveloper 11g jdevstudio11111install.exe

Please download the 2nd and 3rd ones listed above. We’ll start with the 2nd installer from the table above, and then run the 3rd one during Lab 6.

Step 2 Uncompress the labs from the zip file and ensure they exist under the <LAB_HOME> directory. Under this directory, you should have a couple of files and directories for most of the labs.



Step 3 Finally, you will need Oracle XE running on port 1521. You can do a basic install and simply create a user call “WLS” with a password of “WLS” Lab 1 – Product Installation

1. Locate WebLogic installer file within <INSTALL>. You can double click it to run within the GUI. For these screen shots, we show the base package installer for WebLogic.

2. Follow these screen shots to select the installation directory, and install the product.









3. Verify that the installation completed, by looking at the file system within the <INSTALL> directory





Lab 2 – Create a WebLogic Domain This lab will create a domain in 3 different ways. As with the product installation, it can happen either through a GUI or from a command line tool. We’ll use the GUI here, but the command line tool will do everything you can do with the GUI. Appendix B shows you how to invoke the domain wizard from the command line. For this lab, we’ll create 2 domains, one from a “domain template” we will create in a later lab (pre-created for this lab), and again from the standard domain configuration tool. By doing the one from the basic tool, we’ll start “vanilla” and use Lab 3 to create a customized domain we can run with.

Activity 1 – Domain From Template 1. Using the WebLogic Domain Configuration wizard, we’ll complete this and the

next activity. First, we’ll use a pre-packaged domain template (you will create this during Lab 3), which includes a WebLogic domain, a configured connection pool, and a deployed application. This is a typical way to build a production domain, since it ensures consistency with other environments. Although we will use the GUI here, this is entirely scriptable, and allows for cross-platform work.

TIP: As seen in the tooltip above, the executable can run from a prompt and is located at <WLS_INSTALL>/wlserver_10.3/common/bin/config.cmd

2. You will want to create a new domain, base it on a template, and select the

<LAB_HOME>\Lab2_Domains\wls_domain.jar template.





3. Follow the prompts on each screen, leaving the defaults by clicking <enter>.

Not all screens you will see are shown below. Stop when you get to the screen (last screen below) that offers you to customize pre-configured settings.







4. Simply select the defaults here on each screen, but notice that a connection pool and application are already included. Complete the activity by following the screens and completing the domain. At the confirmation screen, select the option to start the domain for you.





5. Verify that the domain starts by running the domain start script. Look for “RUNNING Mode” and the listen port as verification that the server started ok.

6. Using a browser, visit the WLS console, and verify that you can log in as weblogic/weblogic1. Note that you can use “localhost” or your hostname as part of the URL, and this is entirely configurable.





Activity 2 – Domain From Scratch

7. Stop WebLogic that you started from the previous activity. To stop it, you can hit Ctrl+C in the window where WebLogic is running. Or (better for real-life scenarios), there is also a stop script located in the <DOMAIN_HOME>/bin directory that is usually customized and run. The following screen shows the stop script about to be executed from another prompt:

TIP: After hitting <enter> and waiting a moment, you will see the server shut down. Note that the first time WLST is invoked after installation, it is slow, but that subsequent invocations of the stop script will be faster.



8. Delete the entire <DOMAIN_HOME> directory from Windows Explorer. Remember to make sure you have no open command prompts or processes running from this directory. Otherwise it will not delete properly.



9. In order to start from scratch, we’ll create a vanilla WebLogic domain. This time, instead of using a packaged domain template (like we did in Activity 1), we’ll configure the domain as new. Run the same command as step 1, and follow the prompts, making sure to enter the fields as shown: Field Value Domain Name wls_domain WL Username weblogic WL Password weblogic1

NOTE: Appendix B will do this exact step using the command line. This is so you can see that it is the same set of steps without the GUI.





10. For the JDK, you are free to choose, as either will work ok. For this lab, select JRockit. Proceed until the confirmation screen.





11. Before finishing the installer, click the check box to start the Admin Server, as this will save time in navigating to the right location and starting it manually.



12. You should see the command window that WebLogic runs in pop up. To determine that is done starting, look for “RUNNING mode” and the correct listen address above it.



13. Using Firefox, visit the WLS console, and verify that you can log in as weblogic/weblogic1. Note that you can use “localhost” or your hostname as part of the URL, and this is entirely configurable.



TIP: Zip and tar can make domain creation for development even easier. Make zip or tar files as domains are modified in various states. Remember to delete <DOMAIN_HOME>/servers/<ServerName>/tmp/* to reduce zip file size if you started the domain at any point. Although not a lab step, this is how Activity 3 was created.

Activity 3 – Domain via UNZIP

1. Lastly, stop and delete this domain again and simply run the self-extractor (EXE) to “start over”. This is essentially the same step as the previous activities, but will be pre-done for you so that we all have the same starting point. Simply double-click it and select the default location.

2. To finish the activity and prepare for the next lab, start the domain again either from a command prompt at <DOMAIN_HOME>, or by double-clicking the startWebLogic.cmd script from the <DOMAIN_HOME> using Windows Explorer. See the earlier step to confirm the domain is running.



Lab 3 – WLST This lab does several small tasks to take a basic domain we just created, and turn it into one that can be deployed in multiple environments. The WebLogic Scripting Tool (WLST) makes this possible. We’ve included a link in the <LAB_HOME> directory to the tool, but it can be invoked in multiple ways. Refer to Product Documentation for more detail.

Activity 1 – WLST Basics

1. Open a command prompt to c:\Labs. Here you will find a script that will invoke WLST. This simply points to the actual location within the product installation, but ease of running the labs, we’ve put a modified copy here. First run the script on its own with no arguments:

….

2. You are now at a prompt in what is called “offline” mode, which means you aren’t connected to a WebLogic server domain. Here you might do things like create domains, change configuration elements, and build templates for domains. Let’s connect to our running domain from the previous lab to see the “Online” mode of WLST. To do this, use the connect() command: connect('weblogic','weblogic1','t3://localhost:7001')

3. Basic UNIX-style commands are available here, such as pwd(), ls(), and cd(). Run “ls()” to see what is located in the base of the server hierarchy. Note the



left side column, which indicates whether the item is akin to a “directory”, which allows you to use cd(‘the item’) to change your location within the tree.

4. Type exit(), as we aren’t changing anything, or doing anything here just yet. If

time allows, come back to this point and run cd(‘Servers’) as an example to see this tool operating like a UNIX filesystem.

Activity 2 – Script Recording

1. You are welcome to build scripts from scratch, take them from samples and modify them, or share amongst friends. Another way to create scripts that we’ll show here is to “Record” them from the WLS console and modify them. For example, it may be good to remove specific values from scripts, and make them parameterized. In order to do this, we’ll open the WLS console in the browser first.



2. Locate the Change Center at the top left, and lock the console for editing

3. Now click the Script Recording button to start the recording. The console will show you where it is placing the script you will make. It can be helpful to make a dry run first in order to show the exact sequence of commands.



4. Here we will make a change to the server’s configuration and see the resulting script. First, open Environments Servers, then click on AdminServer. Once up, find the “Notes” tab and type something in the box and save it. The following screen shots show this.





5. Your script will be in the <DOMAIN_HOME> directory, ending in a .py extension. Look for something starting with “Script…” that has the current date. Open it with a text editor.

6. You will see that it recorded the directory within the configuration tree and the command it ran to change the Note field. Now open the files called:

<LAB_HOME>\Lab3_WLST\WLS_ServerNote.py <LAB_HOME>\Lab3_WLST\note.properties

You will see that these constitute the changes needed to parameterize the value, as well as the connection string. Study the differences. Finally, make a change to the value in the note.properties file, as this will be reflected in the server configuration.



7. Run the following script from a command prompt at <LAB_HOME>

…

8. Back in the WLS console, refresh and look for the Server’s Notes field to see

the change.



Activity 3 – Domain Configuration via WLST

1. Now we’ll finish configuring the domain by running a few WLST scripts, in order to create a JDBC connection pool, deploy a sample application, and create global role. Run the following scripts from the command prompt you have at <LAB_HOME>, and ensure that they complete without errors. Below you see output from one of the 3 commands.

<LAB_HOME>\Lab3_WLST\WLST_JDBC.py <LAB_HOME>\Lab3_WLST\WLST_Deploy.py <LAB_HOME>\Lab3_WLST\WLST_Global_Role.py

…



TIP: Look at these scripts and start to understand Jython, the WLST syntax, and some of the types of operations that are possible here.

Activity 4 – Package a domain

The final exercise here is to “pack” the domain into a template, which is what you will do to preserve settings and changes made throughout configuring of domains. Packing is also used for creating the incomplete domain directory that is used on remote managed server machines. You can run this via the <LAB_HOME>\Lab3_WLST\packdomain script. Before running it, open it to see that it simply calls the generic WLS pack command, after setting some parameters for convenience.

…



Lab 4 – Troubleshooting This lab will focus on a couple of ways to diagnose problems within a WebLogic Server. There are many ways to do this, and many tools that can help, but for this, we’ll start small and show a couple simple things that can be done from a command line to help.

Activity 1 – Observe Hung Thread For the first activity, we will use a very simplistic application that shows signs of “hanging” somewhat randomly. If enough threads within WebLogic are “hung”, the server could become unresponsive and cause other problems. By using tactics such as taking thread dumps at intervals when the problem is occurring, the source can often be identified.

1. Open a command prompt and deploy the “FlakyApp” application to WebLogic server. This application has a simple servlet that “hangs” every once in a while.

2. From the same prompt prepare to run a thread dump on WebLogic Server. This is probably the most useful form of immediate debugging. In addition, Support personnel will almost always require this to help diagnose and fix issues. We have prepared a WLST script to run the thread dump, and you will get prepared to run this, by typing the following, without hitting <enter>



TIP: Other ways to perform a thread dump are 1) kill -3 <pid> (UNIX), 2) Ctrl-Break (Windows), 3) weblogic.Admin commands, and 4) via the WLS console

3. Open a browser using the URL link from Lab 4. You should see the page load

quickly most of the time, but it is set up to randomly “hang”. Slowly hit Refresh until the status bar stays on “Waiting for localhost” or “Transferring”.

4. While this is occurring, quickly flip back to your command window and hit <enter> where you prepared to run the thread dump command. The FlakyApp gives you 1 minute to do this before the thread completes. In the command window, you should observe one thread that is “stuck” at sleep. For this example, it is trivial. However, this could be a network call, a database call, or any other java code that is causing an issue. Typically you will need to run multiple thread dumps in succession at some interval (5s or so) in order to observe a condition that is outside of normal operation.



5. You now have the source of the issue, along with line numbers, and this is a great starting point for troubleshooting an issue. Note that the script here also pushed a file called “threaddump.txt” out to the local directory.

Activity 2 – Diagnostic Image

1. Another useful item to collect when things are not working is a WebLogic Diagnostic Image. This is a packaged collection of debugging and contextual



information that can be generated easily while a server is misbehaving. WebLogic also gives users the capability to automatically generate one of these under detected conditions that administrators can define. In order to generate one here, we’ll use the script as follows:

In the WebLogic window, you may see this message, which tells us where the diagnostic image will be generated. Unless configured differently, it will go inside the server’s log directory.



Activity 3 – Setting WLS Debug

1. Setting the debug output level for WebLogic is another key part of debugging. Typically applications and platforms print messages of varying severity or importance to log files or the console output. With WebLogic, you have full control over debug information and what is output, and to where. For this exercise, you will change the debug level for JDBC temporarily, and then observe the output in the WebLogic log. The first step is to enable the debug level and debugging parameter for WebLogic JDBC:

2. Next, Alt-Tab back to WebLogic’s window and wait to see the results. You should see the debug statements printed as WebLogic checks the connection pool connection to the database. If this was an application generating queries or something wrong with the database, this might give you a better idea of what is happening.

3. The good thing here is that this can be carefully turned on and off in production using scripts. This can help administrators gather data without restarting servers. To turn it off, run the corresponding debug off script:



TIP: Look at the DEBUG_ON and OFF scripts for ways to potentially parameterize them based on your specific needs. This may require help from scripting knowledge, but is worth the effort.



Lab 5 – Monitoring Monitoring is a broad topic that cannot possibly be completely covered in a single session. There are many ways that administrators use to collect data and watch the WebLogic environment. Some of these include:

Tools such as Oracle Enterprise Manager, Tivoli, HP BAC Scripts run at intervals Command Line (netstat, ps, etc) SNMP tools Load-Generation tools that check actual results WebLogic Console Log file scrapers Java programs that use JMX

Activity 1 – WLST Script

1. The first activity here will be to run a WLST-based status script that checks the heap size of the WebLogic server. This type of script could collect any of the thousands of monitor-able attributes. In this case, the script checks and prints. In a real script, you might take action at this point.



Activity 2 – WebLogic Console

1. Another popular place to monitor WebLogic is the WLS console. Here you will open a browser to WLS Console and look through the server monitoring area. To do this, use the tree on the left to see “Environment” “Servers” “AdminServer”. There are entire areas of the console dedicated to monitoring. Click through the tabs here to see some of what is available:



2. Under the “Performance” tab, you will see that thread dumps can be taken, as

well as a refresh button that will reload this information every 10 seconds:



TIP: The refresh button will cause the console to refresh this information periodically. 3. Log files can also be viewed directly from the console. That can help in not

required shell access to a log message. Filters and limits are built into this section. To see it, use “Diagnostics” “Log Files” and select the log that you need:

4. This area on the left (now under Diagnostic Images) can also help identify

where diagnostic images are stored. Here you should have one that was generated in the previous lab, so here we will open it and look inside of it. Support personnel may be able to understand more than you, but at the very least you will be able to attain some basic information about when the



snapshot was taken. In this case, open it via WinZip and look at the JVM.img file using the internal viewer. This is an XML file, so it is easily readable:

Activity 3 – WLS Console Extension

1. The final piece of monitoring we’ll do is to install and look at the WebLogic Diagnostics Framework Console Extension. This surfaces JMX-based diagnostic information through the WebLogic console, so that it is easily consumable. To install it, simply stop the running server and perform the following file copy operation:

Copy from <WL_HOME>\server\lib\console-ext :



to <DOMAIN_HOME>\console-ext:



2. Restart the server and navigate the browser to the WebLogic Server Console.

Observe the new top-level tab and click on it.

3. Select “JVM Runtime View” and watch for a few seconds. You should observe

free and total memory being graphed over time. This graph can support any number of runtime attributes, and is fully extensible. If time permits, explore the Console extension, add and remove a couple graphable components, and see how the hierarchy relates to what you saw in Lab 3.



Activity 4 – JMX Code (optional) This example shows how to use code to access Java Management Extensions (JMX) that are exposed by WebLogic Server. You may have developers who write this type of code to perform specific tasks or custom monitoring against WebLogic servers or clusters. During this activity, you will use the Eclipse IDE to import a code project and run a JAVA application to connect to WebLogic and obtain information.

1. First, open the Eclipse IDE (Branded as Oracle Enterprise Pack for Eclipse). Create a new workspace and go to the “Workbench” area.



2. Ensure that your WebLogic Server is still running from the previous activity, or start it if you need to.

3. Import the pre-built project by right-clicking in the Project Explorer and selecting “Import”





4. Open the source file called PrintServerState.java.

5. Attempt to run this by using the “Run” button and selecting “Java Application”. This will fail initially because we haven’t assigned the connection parameters to this code yet.



This fails (below) because we haven’t set input parameters yet.

6. To assign parameters, open the “Run Configurations” box, and enter the following information into the “Arguments” panel:



7. Run the program again and observe the results. You will see that the code connected to WebLogic and brought back a piece of information.



8. (Optional) There is another program here called MonitorServlets.java.

Configure and run this to see different information. TIP: Use the Run Configurations to copy/paste parameters to programs that have similar inputs



Lab 6 – JDeveloper and ADF This lab will show you how to install and configure JDeveloper to work with your WebLogic domain. Although JDev comes with a built-in WebLogic domain, it is sometimes helpful to learn to set it up against a free-standing domain which does not run within the IDE.

Activity 1 – Install JDeveloper + ADF

1. As mentioned in Lab 1, you can install either of the standalone WebLogic installers, or you can install the JDeveloper + WebLogic installer. One good thing here is that if you already have the standalone installation, you can simply add to it by running the other installer. Here you see the installer telling us we have a standalone WebLogic and offering to add JDeveloper and ADF to it.



2. Complete the installation by selecting the defaults at each screen. When complete, you can verify the additional products within the installation directory.



Activity 2 – ADF Domain 1. Open the same Domain Configuration wizard we used back in Lab 1. At the

screen which offers the domain types, note that Oracle JRF (ADF) is now an option. Select it for the new domain we’ll create.



2. Complete the wizard using defaults, calling this domain “adf_domain”. The password should be set to “weblogic1”, as it was in the previous domains. Notice that additional applications and components are already deployed, which is made possible using the WebLogic domain templating you have learned.



3. (Optional) Before starting the domain, create a ZIP file of it, so that you can start over without running the wizard again.

4. Start the domain from the command line, as you have done before. It may take longer to start than our vanilla domain did, but that is due to it having more components.

…

5. Open the console in the browser and verify that the domain is running. Under “Deployments”, you will see the components called Oracle Java Required Files (JRF), which allow ADF to function.



Activity 3 – Link JDev to ADF Domain 1. Open JDeveloper 11g from the Start Menu. Select the Default Role and no to

the migration question.



2. After accepting the defaults, changing file associations, and answering other dialogs that may come up, you see that JDev goes and creates its “Integrated Domain”, which you can use with ADF applications. Activity 2 created a standalone domain, which is more typical of what you will find in anything but a developer workstation.

3. Create a new Fusion Web application called “ADFApp”. This is not meant to be an ADF tutorial, but rather to show the ease of connectivity. After naming the application, click Finish to complete the process.



4. Make a new JSF Page as shown, and add some content to the center pane so it will show something in a browser.





5. Click run (F11) and watch as JDev compiles the application and starts the default server of WebLogic. After this is complete, the page we created should appear in the browser.



6. In order to switch this to our domain, close out of the browser and stop the running “Default Server” from JDev. After we switch it use ours, this will not occur again.

7. To switch domains, use the application dialog, which is the icon above the context menu in this screen shot. Select “Application Properties” and look for the Run section. You should see the Default Server listed as the “Bind Application to” parameter. Click “Edit Server Instances”







8. From this dialog, you will define a new connection to our domain, and in the previous dialog, you will then select it as the default for running ADF applications against. After clicking “New…”, you will click the green + sign and create an actual WebLogic Server connection. Proceed to the testing screen using the correct domain name (adf_domain), username (weblogic), and password (weblogic1).









9. Test the connection as shown and ensure that all of the tests are successful.



10. Finish and name the new Server Connection



11. Finally, select the new domain connection as the default for the application, back in the Application Properties window.



12. Now, when running the application from within JDeveloper, you should see it use our domain for the application. You can tell it is because our domain is port 7001 and the Integrated one was 7101.

…



Appendix A – Command-Line Installation Lab 1 showed you a simple product installation using the default options. If you are operating on a system without GUI access, such as a remote Linux or Solaris box, it is helpful to see the command line installer being run. It will essentially do the same thing as the GUI version from Lab 1, but is console-driven. Invoke the installer by opening a command prompt from the Windows start menu. Navigate to the <INSTALL> directory and execute the command as shown:

oepe11_wls1031.exe -mode=console

…



Appendix B – Console Mode Domain From a command prompt (any directory), run the following command. Hit <enter> on the first screen to create a new domain. c:\weblogic\wlserver_10.3\common\bin\config.cmd -mode=console

Documents

WLS Admin 11gR1 Lab Guide