Thursday, 14 July 2016

Set connection retry frequency on DataSource in WebLogic 12c.

I have encountered several times in WebLogic 12c that when the ConnectionPool of a DataSource in WebLogic could not be initialized because due to a connection error or invalid username or password, the server could not be started.

I can't remember having encounterd this problem in 11g, and this week I struggled with it with one of my customers. The perception of the DBA there was that in 11g the server did start up, but the DataSource would go in Suspended-state. Half a year ago, one of the admins just removed a datasource because it made the 12c WebLogic server unstartable. "Taking a short turn", we would say in Dutch.

Now, having a database that is down is a reality at my customers. At least in development and test environments. Also at some of my customers it is a reality to have databases refreshed with an earlier clone. Causing for instance database passwords becoming invalid. It's quite inconvenient not being able to start the servers. Especially when the AdminServer can't be started because of it. And with SOASuite and OSB this is a reality since some of the consoles and composers are targeted to the AdminServer.

This week I found there were 2 options to get the server started:
  • Temporarily untarget the datasource
  • Set the initial and minimum connections to 0. 
The first was acceptable for one of my customers because they have just one cluster to which the problematic datasources was targeted to. Untargeting would leave all the other settings. And retargetting doesn't raise questions because there's only one target option.

But in a complex domain with several clusters it might not be too obvious to which cluster(s) or server(s) the datasource should be retargeted.

Changing the initial/minimum connections is not ideal either. Because you need to remember what the preferred settings were. These are important when using them for web applications or services used by web applications where performance is key.

But today I stumbled upon a third option: 'Connection Creation Retry Frequency' which can be found under DataSource -> Configuration -> Connection Pool -> Advanced:

Set this to 300 to have a retry every 5 minutes. It is described as:
The number of seconds between attempts to establish connections to the database.

If you do not set this value, data source creation fails if the database is unavailable. If set and if the database is unavailable when the data source is created, WebLogic Server will attempt to create connections in the pool again after the number of seconds you specify, and will continue to attempt to create the connections until it succeeds.

When set to 0, connection retry is disabled.'

Learning all the time...



Start and stop a WebLogic (SOA/OSB) Domain

So let's start the day with a blog. In the past few months I created scripts to install FMW products and build a WebLogic domain for it. For most of my findings I did a blog already:
And then I did not list the blogs about the scripts to setup and patch the QuickStarts. Nice  to mention is that this week 12.2.1.1 is released. So I can adapt my scripts with the new software (I'm not going to post that, you should be able to figure that out yourself, maybe I'll provide the changed snippets when I come to it).

But the important missing part in this series are the start and stop of the domain. So let me provide and describe my scripts.

Oracle does provide scripts to start and stop your NodeManager and WebLogic servers. When you configure the NodeManager and Servers correctly you can use those to add the NodeManager to the init.d services on Linux or to your Windows Services. Then the NodeManager would start the AdminServer and other Servers automatically.

However, on my demo/training/development systems I'd like to be able to start/stop the parts myself.  So here we go.

Settings

I'm working with Linux and create shell scripts to kick-off the wlst scripts that I use to start the particular components. Therefor I use a settings script called fmw12c_env.sh to call the setWLSEnv.sh from the FMW home. I take it that you're able to translate them to Windows Command file if applicable. I provided it a couple of time already. But for completeness here it is:
#!/bin/bash
echo set Fusion MiddleWare 12cR2 environment
export FMW_HOME=/u01/app/oracle/FMW12210
export NODEMGR_HOME=/u01/app/work/domains/osb_domain/nodemanager

export SOA_HOME=$FMW_HOME/soa
export OSB_HOME=$FMW_HOME/osb
export MFT_HOME=$FMW_HOME/mft
#
echo call setWLSEnv.sh
. $FMW_HOME/wlserver/server/bin/setWLSEnv.sh
export PATH=$FMW_HOME/oracle_common/common/bin:$WL_HOME/common/bin/:$WL_HOME/server/bin:$PATH

Then the wlst scrips need a property file fmw.properties:
#############################################################################
# Set SOABPM Domain properties
#
# @author Martien van den Akker, Darwin-IT Professionals
# @version 1.0, 2016-06-27
#
#############################################################################
#
#Per domain nodemanager...
#############################################################################
# Set SOABPM Domain properties
#
# @author Martien van den Akker, Darwin-IT Professionals
# @version 1.0, 2016-06-27
#
#############################################################################
#
#Per domain nodemanager...
#nmHome=/u01/app/work/domains/osb_domain/nodemanager
nmHome=/u01/app/work/domains/soabpm_domain/nodemanager
#nmHome=/u01/app/work/domains/soabpm12c_dev/nodemanager
nmHost=darlin-vce-db
nmPort=5555
nmType=plain
#
#Domain
#wlsDomainName=osb_domain
#wlsDomainName=soabpm12c_dev
wlsDomainName=soabpm_domain
wlsDomainsHome=/u01/app/work/domains
#
#AdminServer
adminServerName=AdminServer
#adminServerName=OsbAdmin
adminUrl=darlin-vce-db:7001
adminUser=weblogic
adminPwd=welcome1
usrCfgFile=wlsCfgFile
usrKeyFile=wlsKeyFile
#Clusters
osbClr=OsbCluster
soaClr=SoaCluster

Create User Config and Key files

In the property file above you'll see the adminUser and adminPwd (password). On a production environment you probably don't want to have those in plain sight. WebLogic provides a means to encrypt those in to a user config and a key file. When you generate those with the default names to your home folder you even can connect to the AdminServer without providing the username/password. In my scripts I use named files as defined in the usrCfgFile and usrKeyFile properties. But first we need to generate those and for that we need to connect to the AdminServer using the adminUser and adminPwd properties.

I created the script createUserConfigFiles.py to generate those files:
#############################################################################
# Stop AdminServer 
#
# @author Martien van den Akker, Darwin-IT Professionals
# @version 2.1, 2016-06-27
#
#############################################################################
# Modify these values as necessary
import sys, traceback
scriptName = 'stopAdmin.py'
#
#
lineSeperator='__________________________________________________________________________________'
#
#
def usage():
  print 'Call script as: '
  print 'Windows: wlst.cmd '+scriptName+' -loadProperties localhost.properties'
  print 'Linux: wlst.sh '+scriptName+' -loadProperties environment.properties'
  print 'Property file should contain the following properties: '
  print "adminUrl=localhost:7101"
  print "adminUser=weblogic"
  print "adminPwd=welcome1"
#
#
def main():
  try:
    print(lineSeperator)
    print('Create user config files')
    print(lineSeperator)
    print('\nConnect to the AdminServer: '+adminServerName)
    connect(adminUser, adminPwd, adminUrl)
    #
    print('\nStore Config files')
    storeUserConfig(usrCfgFile,usrKeyFile)
    #   
    print('\nExiting...')
  except NameError, e:
    print('Apparently properties not set.')
    print "Please check the property: ", sys.exc_info()[0], sys.exc_info()[1]
    usage()
  except:
    apply(traceback.print_exception, sys.exc_info())
    stopEdit('y')
    exit(exitcode=1)
#
main();

After connecting to the AdminServer it is the storeUserConfig(usrCfgFile,usrKeyFile) that creates the files. If you don't supply the parameters it will create the default files in your home folder (for instance /home/oracle), then you can connect just by issueing connect('localhost:7001'). For more on this, read this blog.

To call the script above you can use the script createUserConfigFiles.sh or the contents of it:
#!/bin/bash
#############################################################################
# Create user config files using wlst.sh
#
# @author Martien van den Akker, Darwin-IT Professionals
# @version 2.1, 2016-06-27
#
#############################################################################
#  
. fmw12c_env.sh
echo
echo Create User Config files
wlst.sh ./createUserConfigFiles.py -loadProperties fmw.properties

After having greated the files you can (and should!) remove the adminUser and adminPwd properties from the fmw.properties file.

Start the NodeManager

 In de domain home/bin folder (for instance /u01/app/work/domains/soabpm_domain/bin) you'll find scripts to start and stop the NodeManager: startNodeManager.sh and stopNodeManager.sh. These are fine to use in the service configurations in Linux or Windows.

However, running them from the shell/command line will cause your session to be taken for the NodeManager. Stopping the session will cause the NodeManager to be stopped. Not so handy if you want to start the NodeManager in an overall script that starts the complete domain.

But you can start the NodeManager from wlst as well. And then it spawns the NodeManager into a seperate process in  the background.
The script startNodeManager.py is quite simple:
#############################################################################
# Start nodemanager
#
# @author Martien van den Akker, Darwin-IT Professionals
# @version 2.1, 2016-06-27
#
#############################################################################
# Modify these values as necessary
import sys, traceback
scriptName = sys.argv[0]
#
#
lineSeperator='__________________________________________________________________________________'
#
#
def usage():
  print 'Call script as: '
  print 'Windows: wlst.cmd '+scriptName+' -loadProperties localhost.properties'
  print 'Linux: wlst.sh '+scriptName+' -loadProperties environment.properties'
  print 'Property file should contain the following properties: '
  print "adminUrl=localhost:7101"
  print "adminUser=weblogic"
  print "adminPwd=welcome1"
# 
# 
def startNM(nmHost, nmPort, nmHome, nmType):
  print(lineSeperator)
  print ('Start NodeManager')
  startNodeManager(verbose='true', NodeManagerHome=nmHome, ListenPort=nmPort, ListenAddress=nmHost);
  print('Finished starting NodeManager')
#
def main():
  try:
    startNM(nmHost, nmPort, nmHome,  nmType);
  except NameError, e:
    print('Apparently properties not set.')
    print "Please check the property: ", sys.exc_info()[0], sys.exc_info()[1]
    usage()
  except:
    apply(traceback.print_exception, sys.exc_info())
    stopEdit('y')
    exit(exitcode=1)
#
main()

It's mainly about the startNodeManager(verbose='true', NodeManagerHome=nmHome, ListenPort=nmPort, ListenAddress=nmHost) statement in the  startNM() function, which is quite self explaining, I think.  No username password is required to start the NodeManager, but it does need to know what it's home and listenPort and Address should be.

As with all the scripts I  declare a scripName variable with the assignment of the 0-th argument: sys.argv[0]. This is used in the usage() function that is called in case of a NameError exception. This exception is raised when certain variable or function references are made but not found. Normally this would mean that a certain property is not set in the property file.

To run it from the shell you can use the startNodeManager.sh script:

#!/bin/bash
#############################################################################
# Start nodemanager using wlst
#
# @author Martien van den Akker, Darwin-IT Professionals
# @version 2.1, 2016-06-27
#
#############################################################################
#  
. fmw12c_env.sh
echo
echo Start NodeManager
wlst.sh ./startNodeManager.py -loadProperties fmw.properties
For every python script in the procession of this blog I have an accompanying shell script like this. So I won't provide those for the other scripts.

Stopping the NodeManager is a little more complicated:
#############################################################################
# Stop nodemanager
#
# @author Martien van den Akker, Darwin-IT Professionals
# @version 2.1, 2016-06-27
#
#############################################################################
# Modify these values as necessary
import sys, traceback
scriptName = sys.argv[0]
#
#
lineSeperator='__________________________________________________________________________________'
#
#
def usage():
  print 'Call script as: '
  print 'Windows: wlst.cmd '+scriptName+' -loadProperties localhost.properties'
  print 'Linux: wlst.sh '+scriptName+' -loadProperties environment.properties'
  print 'Property file should contain the following properties: '
  print "adminUrl=localhost:7101"
  print "adminUser=weblogic"
  print "adminPwd=welcome1"
# 
#
def connectToNM(nmHost, nmPort, nmHome, wlsDomainName, wlsDomainHome, nmType):
  try:
    print(lineSeperator)
    print('Try to connect to the Node Manager')
    try:
      nmConnect(userConfigFile=usrCfgFile, userKeyFile=usrKeyFile, host=nmHost, port=nmPort, domainName=wlsDomainName, domainDir=wlsDomainHome, nmType=nmType)
    except NameError, e:
      print('Apparently user config properties usrCfgFile and usrKeyFile not set.')
      print('Try to connect to the NodeManager adminUser and adminPwd properties')
      nmConnect(username=adminUser, password=adminPwd, host=nmHost, port=nmPort, domainName=wlsDomainName, domainDir=wlsDomainHome, nmType=nmType)
    print('Connected to the Node Mananger')
  except WLSTException:
    message='Apparently NodeManager not Started!'
    print (message)
    raise Exception(message)
# 
# 
def stopNM(nmHost, nmPort, nmHome, wlsDomainName, wlsDomainHome, nmType):
  try:
    print(lineSeperator)
    print ('Try to connect to the Node Manager')
    connectToNM(nmHost, nmPort, nmHome, wlsDomainName, wlsDomainHome, nmType);
    print ('Connected to the Node Mananger')
    print ('Stop the NodeManager')
    stopNodeManager();
    print('Finished stapping NodeManager')
  except WLSTException:
    print ('Apparently NodeManager not Started!')
#
def main():
  try:
    wlsDomainHome = wlsDomainsHome+'/'+wlsDomainName
    stopNM(nmHost, nmPort, nmHome, wlsDomainName, wlsDomainHome, nmType);
  except NameError, e:
    print('Apparently properties not set.')
    print "Please check the property: ", sys.exc_info()[0], sys.exc_info()[1]
    usage()
  except:
    apply(traceback.print_exception, sys.exc_info())
    stopEdit('y')
    exit(exitcode=1)
#
main()

You first need to connect to the NodeManager. This is done in connectToNM() that illustrates the use of the user config and key files with the adminUser/adminPwd properties as a fall back. First it tries to connect using the userConfigFile/userKeyFile combination. If that leads to a NameError, then you probably did not provide those, so it retries it on with the adminUser/adminPwd properties.
This construct is reused when trying to connect to the AdminServer to start the rest of the domain.
When it is connected the nodeManager can be stopped, simply with the stopNodeManager() command.

Start/Stop the AdminServer

The startAdmin.py provided below is used to Start the Admin Server. Again, there are  startWeblogic.sh and stopWeblogic.sh scripts in the bin folder of the domain. But those will start the server in the foreground (although you can move them to the background of course). But mainly the servers aren't under control of the NodeManager, what has it's advantages. So the startAdmin.py script:
#############################################################################
# Start AdminServer via NodeManager and try to connect to it.
# Result of this script should be that you are connect to the AdminServer.
#
# @author Martien van den Akker, Darwin-IT Professionals
# @version 2.1, 2016-06-27
#
#############################################################################
# Modify these values as necessary
import sys, traceback
scriptName = sys.argv[0]
#
#
lineSeperator='__________________________________________________________________________________'
#
#
def usage():
  print 'Call script as: '
  print 'Windows: wlst.cmd '+scriptName+' -loadProperties localhost.properties'
  print 'Linux: wlst.sh '+scriptName+' -loadProperties environment.properties'
  print 'Property file should contain the following properties: '
  print "adminUrl=localhost:7101"
  print "adminUser=weblogic"
  print "adminPwd=welcome1"
# 
#
def connectToNM(nmHost, nmPort, nmHome, wlsDomainName, wlsDomainHome, nmType):
  try:
    print(lineSeperator)
    print('Try to connect to the Node Manager')
    try:
      nmConnect(userConfigFile=usrCfgFile, userKeyFile=usrKeyFile, host=nmHost, port=nmPort, domainName=wlsDomainName, domainDir=wlsDomainHome, nmType=nmType)
    except NameError, e:
      print('Apparently user config properties usrCfgFile and usrKeyFile not set.')
      print('Try to connect to the NodeManager adminUser and adminPwd properties')
      nmConnect(username=adminUser, password=adminPwd, host=nmHost, port=nmPort, domainName=wlsDomainName, domainDir=wlsDomainHome, nmType=nmType)
    print('Connected to the Node Mananger')
  except WLSTException:
    message='Apparently NodeManager not Started!'
    print (message)
    raise Exception(message)
    #print 'Start Nodemanager'
    #startNodeManager(verbose='true', NodeManagerHome=nmHome, ListenPort=nmPort, ListenAddress=nmHost);
    #print 'Retry to connect to the Node Manager';
    #nmConnect(username=adminUser, password=adminPwd, host=nmHost, port=nmPort, domainName=wlsDomainName, domainDir=wlsDomainHome, nmType=nmType);
#
#
def connectToadminServer(adminUrl, adminServerName):
  try:
    print(lineSeperator)
    print('Try to connect to the AdminServer')
    try:
      connect(userConfigFile=usrCfgFile, userKeyFile=usrKeyFile, url=adminUrl)
    except NameError, e:
      print('Apparently user config properties usrCfgFile and usrKeyFile not set.')
      print('Try to connect to the AdminServer adminUser and adminPwd properties')
      connect(adminUser, adminPwd, adminUrl)
  except WLSTException:
    print('Apparently AdminServer not Started!')
    print('Start AdminServer')
    nmStart(adminServerName)
    print('Retry to connect to the AdminServer')
    try:
      connect(userConfigFile=usrCfgFile, userKeyFile=usrKeyFile, url=adminUrl)
    except NameError, e:
      print('Apparently user config properties usrCfgFile and usrKeyFile not set.')
      print('Try to connect to the AdminServer adminUser and adminPwd properties')
      connect(adminUser, adminPwd, adminUrl)
#
#
def main():
  try:
    wlsDomainHome = wlsDomainsHome+'/'+wlsDomainName
    print(lineSeperator)
    print('Start '+adminServerName+' for domain in : '+wlsDomainHome)
    print(lineSeperator)
    print ('Connect to the Node Manager')
    connectToNM(nmHost, nmPort, nmHome, wlsDomainName, wlsDomainHome, nmType)
    print ('Connect to the AdminServer: '+adminServerName)
    connectToadminServer(adminUrl, adminServerName)
  except NameError, e:
    print('Apparently properties not set.')
    print "Please check the property: ", sys.exc_info()[0], sys.exc_info()[1]
    usage()
  except:
    apply(traceback.print_exception, sys.exc_info())
    exit(exitcode=1)
#
main();

The script first uses connectToNM(nmHost, nmPort, nmHome, wlsDomainName, wlsDomainHome, nmType) to connect to the NodeManager. Just in the same way as in the stopNodeManager.py script.
Then it tries to connect to the AdminServer using connectToadminServer(adminUrl, adminServerName). Now, the connect to the NodeManager might be a little over done. But in the connectToadminServer() function it tries to connect to the AdminServer the same way as to the NodeManager: first with the userConfigFile, userKeyFile combination. But when those properties aren't set, it uses the username password combination. If a connection to the AdminServer fails, the function concludes that it isn't started yet. But since it is still connected to the nodemanager it can start the AdminServer using nmStart(adminServerName). So it is important that in the adminServerName property in the fmw.properties the correct name of the AdminServer is given.

To stop the admin server I have the stopAdmin.py script:
#############################################################################
# Stop AdminServer 
#
# @author Martien van den Akker, Darwin-IT Professionals
# @version 2.1, 2016-06-27
#
#############################################################################
# Modify these values as necessary
import sys, traceback
scriptName = sys.argv[0]
#
#
lineSeperator='__________________________________________________________________________________'
#
#
def usage():
  print 'Call script as: '
  print 'Windows: wlst.cmd '+scriptName+' -loadProperties localhost.properties'
  print 'Linux: wlst.sh '+scriptName+' -loadProperties environment.properties'
  print 'Property file should contain the following properties: '
  print "adminUrl=localhost:7101"
  print "adminUser=weblogic"
  print "adminPwd=welcome1"
#
#
def connectToadminServer( adminUrl, adminServerName):
  try:
    print(lineSeperator)
    print('Try to connect to the AdminServer using user config')
    connect(userConfigFile=usrCfgFile, userKeyFile=usrKeyFile, url=adminUrl)
  except NameError, e:
    print('Apparently user config properties usrCfgFile and usrKeyFile not set.')
    print('Try to connect to the AdminServer adminUser and adminPwd properties')
    connect(adminUser, adminPwd, adminUrl)
  except WLSTException:
    message='Apparently AdminServer not Started!'
    print (message)
    raise Exception(message)
#
#
def main():
  try:
    wlsDomainHome = wlsDomainsHome+'/'+wlsDomainName
    print(lineSeperator)
    print('Stop '+adminServerName+' for domain in : '+wlsDomainHome)
    print(lineSeperator)
    print('\nConnect to the AdminServer: '+adminServerName)
    connectToadminServer(adminUrl, adminServerName)
    #
    print('\nShutdown the AdminServer: '+adminServerName)
    shutdown(force='true')
    #
    print('\nFinished stopping AdminServer: '+adminServerName)
  except NameError, e:
    print('Apparently properties not set.')
    print "Please check the property: ", sys.exc_info()[0], sys.exc_info()[1]
    usage()
  except:
    apply(traceback.print_exception, sys.exc_info())
    exit(exitcode=1)
#
main();

This one does a connect to the AdminServer (in the same two layer approach), and when connected it performs a shutdown(force='true'). This is equivalant to the 'Force Shutdown Now' option in the console. Since no server or cluster name is provided the AdminServer is shutdown.

Start&Stop Domain

In my create domain scripts I create clusters for every component. Even when I have only one managed server (for instance in a development environment) I added the servers to a cluster. This makes it easier to expand the domain with multiple nodes. And it makes the management the same for every environment.

So to start and stop the domain I work per cluster. The nice thing then is that when connected you can just issue a start cluster command and the AdminServer uses the different nodeManagers on the hosts to start the servers simultaneously. This reduces the startup time significantly compared to starting the servers of a cluster one by one.

 Now, it might be that one of the servers couldn't be started right away. And this fails the start cluster command. So I added a little code to try to start the different servers one by one. I think it is somewhat over done in most cases, but it does illustrate some functions to figure out the servers to start and to determine their state. So here is my startDomain.py script:
#############################################################################
# Start SOA and OSB domain
#
# @author Martien van den Akker, Darwin-IT Professionals
# @version 1.1, 2016-06-27
#
#############################################################################
# Modify these values as necessary
import sys, traceback
scriptName = sys.argv[0]
#
#
lineSeperator='__________________________________________________________________________________'
#
#
def usage():
  print 'Call script as: '
  print 'Windows: wlst.cmd '+scriptName+' -loadProperties localhost.properties'
  print 'Linux: wlst.sh '+scriptName+' -loadProperties environment.properties'
  print 'Property file should contain the following properties: '
  print "adminUrl=localhost:7001"
  print "adminUser=weblogic"
  print "adminPwd=welcome1"
# 
#
def connectToNM(nmHost, nmPort, nmHome, wlsDomainName, wlsDomainHome, nmType):
  try:
    print(lineSeperator)
    print('Try to connect to the Node Manager')
    try:
      nmConnect(userConfigFile=usrCfgFile, userKeyFile=usrKeyFile, host=nmHost, port=nmPort, domainName=wlsDomainName, domainDir=wlsDomainHome, nmType=nmType)
    except NameError, e:
      print('Apparently user config properties usrCfgFile and usrKeyFile not set.')
      print('Try to connect to the NodeManager adminUser and adminPwd properties')
      nmConnect(username=adminUser, password=adminPwd, host=nmHost, port=nmPort, domainName=wlsDomainName, domainDir=wlsDomainHome, nmType=nmType)
    print('Connected to the Node Mananger')
  except WLSTException:
    message='Apparently NodeManager not Started!'
    print (message)
    raise Exception(message)
    #print 'Start Nodemanager'
    #startNodeManager(verbose='true', NodeManagerHome=nmHome, ListenPort=nmPort, ListenAddress=nmHost);
    #print 'Retry to connect to the Node Manager';
    #nmConnect(username=adminUser, password=adminPwd, host=nmHost, port=nmPort, domainName=wlsDomainName, domainDir=wlsDomainHome, nmType=nmType);
#
#
def connectToadminServer(adminUrl, adminServerName):
  try:
    print(lineSeperator)
    print('Try to connect to the AdminServer')
    try:
      connect(userConfigFile=usrCfgFile, userKeyFile=usrKeyFile, url=adminUrl)
    except NameError, e:
      print('Apparently user config properties usrCfgFile and usrKeyFile not set.')
      print('Try to connect to the AdminServer adminUser and adminPwd properties')
      connect(adminUser, adminPwd, adminUrl)
  except WLSTException:
    print('Apparently AdminServer not Started!')
    print('Start AdminServer')
    nmStart(adminServerName)
    print('Retry to connect to the AdminServer')
    try:
      connect(userConfigFile=usrCfgFile, userKeyFile=usrKeyFile, url=adminUrl)
    except NameError, e:
      print('Apparently user config properties usrCfgFile and usrKeyFile not set.')
      print('Try to connect to the AdminServer adminUser and adminPwd properties')
      connect(adminUser, adminPwd, adminUrl)
#
# Get the Servers of Cluster 
def getClusterServers(clustername):
  #Cluster config to be fetched from ServerConfig
  print(lineSeperator)
  print('\nGet Servers from cluster '+clustername)
  serverConfig()
  cluster = getMBean("/Clusters/" + clustername)
  if cluster is None:
    errorMsg= "Cluster " + clustername + " does not appear to exist!"
    print errorMsg
    raise(Exception(errorMsg))
  print "Found cluster "+ clustername+ "."
  servers = cluster.getServers()
  return servers
#
#
def serverStatus(serverName):
  serverRuntime=getMBean('/ServerRuntimes/'+serverName)
  if serverRuntime is None:
    print("Server Runtime for  " + serverName + " not found, server apparently SHUTDOWN")
    serverState="SHUTDOWN"
  else:
    print "Found Server Runtime for "+ serverName+ "."
    serverState = serverRuntime.getState()
  return serverState
#
#
def startClusterServersOneByOne(clusterName):
  print(lineSeperator)
  print ('Start servers for cluster: '+clusterName)
  servers=getClusterServers(clusterName)
  # Need to go to domainRuntime to get to the serverRuntimes.
  domainRuntime()
  #
  for server in servers:
    print(lineSeperator)
    serverName = server.getName()
    print('ServerName: '+serverName)
    serverState = serverStatus(serverName)
    print('Server '+serverName+': '+serverState)
    if serverState=="SHUTDOWN":
      print ('Server '+serverName+' is not running so start it.')
      start(serverName)
    elif serverState=="RUNNING":
      print ('Server '+serverName+' is already running')
    else:
      print ('Server '+serverName+' in state '+serverState+', not startable!')
  #
  print ('\nFinished starting servers.')
#
#
def startClusterServers(clusterName):
  print(lineSeperator)
  print ('Start servers for cluster: '+clusterName)
  #
  try:
    start(clusterName,'Cluster')
  except WLSTException:
    print "Apparently Cluster in incompatible state!", sys.exc_info()[0], sys.exc_info()[1]
    startClusterServersOneByOne(clusterName)
  state(clusterName,'Cluster')
  #
  print ('\nFinished starting servers.')
#
#
def main():
  try:
    wlsDomainHome = wlsDomainsHome+'/'+wlsDomainName
    print (lineSeperator)
    print ('Start Osb Cluster')
    print('\nConnect to AdminServer ')
    print (lineSeperator)
    print ('Connect to the Node Manager')
    connectToNM(nmHost, nmPort, nmHome, wlsDomainName, wlsDomainHome, nmType)
    print ('Connect to the AdminServer: '+adminServerName)
    connectToadminServer(adminUrl, adminServerName)
    #
    print('Start servers for cluster: '+osbClr)
    startClusterServers(osbClr)
    #
    print('Start servers for cluster: '+soaClr)
    startClusterServers(soaClr)
    #
    print('\nExiting...')
    exit()
  except NameError, e:
    print('Apparently properties not set.')
    print "Please check the property: ", sys.exc_info()[0], sys.exc_info()[1]
    usage()
  except:
    apply(traceback.print_exception, sys.exc_info())
    exit(exitcode=1)
#call main()
main()
exit()

It first connects to the AdminServer in the familiar way. If that fails it tries to start it. So far it is copied from the startAdmin.py script. Then it calls the startClusterServers(clusterName) function for each cluster. You need to add each cluster here by hand. I could loop over the clusternames, but you might need to have them started in a certain order. This function first issues the start(clusterName,'Cluster') command. Providing the 'Cluster' parameter as a start type, a complete cluster can be started. If that fails, then apparently one or more servers failed to start. If so it tries to start the servers one by one in the startClusterServersOneByOne(clusterName) function. It gets the servers attached to the cluster using getClusterServers(clustername) function. This is done using the getServers() method of the cluster. This needs to be done in the serverConfig() state. After that for each server the status is fetched by querying the serverRuntime of the server in the serverStatus() function. ServerRuntimes are available in the DomainRuntime() state, so it is needed to switch the state using that function. If the ServerRuntime is not avaiable, the state is considered to be 'SHUTDOWN'. If the server is down a start(serverName) is issued. Lastly in the startClusterServers() function the state(clusterName,'Cluster') is called to print the state of the servers in the cluster.

To Stop the domain I created the stopDomain.py which mainly works in reverse:
#############################################################################
# Stop OSB Domain
#
# @author Martien van den Akker, Darwin-IT Professionals
# @version 1.1, 2016-06-27
#
#############################################################################
# Modify these values as necessary
import sys, traceback
scriptName = sys.argv[0]
#
#
lineSeperator='__________________________________________________________________________________'
#
#
def usage():
  print 'Call script as: '
  print 'Windows: wlst.cmd '+scriptName+' -loadProperties localhost.properties'
  print 'Linux: wlst.sh '+scriptName+' -loadProperties environment.properties'
  print 'Property file should contain the following properties: '
  print "adminUrl=localhost:7001"
  print "adminUser=weblogic"
  print "adminPwd=welcome1"
#
#
def connectToadminServer(adminUrl, adminServerName):
  try:
    print(lineSeperator)
    print('Try to connect to the AdminServer')
    try:
      connect(userConfigFile=usrCfgFile, userKeyFile=usrKeyFile, url=adminUrl)
    except NameError, e:
      print('Apparently user config properties usrCfgFile and usrKeyFile not set.')
      print('Try to connect to the AdminServer adminUser and adminPwd properties')
      connect(adminUser, adminPwd, adminUrl)
  except WLSTException:
    message='Apparently AdminServer not Started!'
    print (message)
    raise Exception(message)
#
# Get the Servers of Cluster 
def getClusterServers(clustername):
  #Cluster config to be fetched from ServerConfig
  print(lineSeperator)
  print('\nGet Servers from cluster '+clustername)
  serverConfig()
  cluster = getMBean("/Clusters/" + clustername)
  if cluster is None:
    errorMsg= "Cluster " + clustername + " does not appear to exist!"
    print errorMsg
    raise(Exception(errorMsg))
  print "Found cluster "+ clustername+ "."
  servers = cluster.getServers()
  return servers
#
#
def serverStatus(serverName):
  serverRuntime=getMBean('/ServerRuntimes/'+serverName)
  if serverRuntime is None:
    print("Server Runtime for  " + serverName + " not found, server apparently SHUTDOWN")
    serverState="SHUTDOWN"
  else:
    print "Found Server Runtime for "+ serverName+ "."
    serverState = serverRuntime.getState()
  return serverState
#
#
def stopClusterServers(clusterName):
  print(lineSeperator)
  print ('Stop servers for cluster: '+clusterName)
  #
  try:
    shutdown(clusterName,'Cluster')
  except WLSTException:
    print "Apparently Cluster in incompatible state!", sys.exc_info()[0], sys.exc_info()[1]
    state(clusterName,'Cluster')
    print ('Try to stop servers for cluster: '+clusterName+', one by one')
    servers=getClusterServers(clusterName)
    # Need to go to domainRuntime to get to the serverRuntimes.
    domainRuntime()
    #
    for server in servers:
      print(lineSeperator)
      serverName = server.getName()
      print('ServerName: '+serverName)
      serverState = serverStatus(serverName)
      print('Server '+serverName+': '+serverState)
      if serverState=="RUNNING":
        print ('Server '+serverName+' is running so shut it down.')
        shutdown(name=serverName, force='true')
      elif serverState=="SHUTDOWN":
        print ('Server '+serverName+' is already down.')
      else:
        print ('Server '+serverName+' in state '+serverState+', not stoppable!')
  #
  print ('\nFinished stopping servers.')
#
#
def main():
  try:
    wlsDomainHome = wlsDomainsHome+'/'+wlsDomainName
    print (lineSeperator)
    print ('Stop Osb Domain')
    print (lineSeperator)
    print('\nConnect to the AdminServer: '+adminServerName)
    connectToadminServer(adminUrl, adminServerName)
    print(lineSeperator)
    print('First stop servers from cluster '+osbClr)
    stopClusterServers(osbClr)
    #
    print(lineSeperator)
    print('\nShutdown the AdminServer: '+adminServerName)
    shutdown(force='true')
    print ('\nFinished stopping servers.')
    #
    print('\nExiting...')
    exit()
  except NameError, e:
    print('Apparently properties not set.')
    print "Please check the property: ", sys.exc_info()[0], sys.exc_info()[1]
    usage()
  except:
    apply(traceback.print_exception, sys.exc_info())
    exit(exitcode=1)
#call main()
main()
exit()

In the sameway as in starting the servers this script first tries to shutdown the cluster as a whole. The AdminServer takes advantage of the NodeManager to simulaneously stop the servers. The NodeManager first tries to connect to the particular server to hand over a suicide pill. But if it can't reach the server directly it releases it from suffering by doing an explicit OS-Level kill process...
After the shutdown of the servers the AdminServer is shut down.

Conclusion

This concludes this article on starting and stopping your domain. I hope it was enlighting and entertaining. One improvements  would be to reuse the scripts on starting and stopping the AdminServer in the starting and stopping of the Domain. You see that there is some code-overlap. But the way I call them with an explicit property file prevents doing a execfile(). But the properties loaded aren't passed to the execfile() apparently. And it needs a path to the other file. So that's why I for now combined the code into one script.

Wednesday, 13 July 2016

Create WebLogic users for ServiceBus 12c - Part 2

Last week I wrote a blog about how to create WebLogic users for ServiceBus 12c. However, I did not now how to assign a particular Application Specific Role to the weblogic user, for particular ServiceBus privileges. I did find out what particular Roles there were (see the blog). But how to assign them I found out just today.

So here it is:
#
#
def grantOSBAppRoleToWlsGroup(osbAppRole, wlsGroup):
    #
    # Grant OSB AppRole
    # http://docs.oracle.com/cd/E23943_01/web.1111/e13813/custom_infra_security.htm#WLSTC1398
    # grantAppRole(appStripe, appRoleName,principalClass, principalName)
    # appStripe: Specifies an application stripe.
    # appRoleName: Specifies a role name.
    # principalClass: Specifies the fully qualified name of a class.
    # principalName: Specifies the principal name.
    #grantAppRole("Service_Bus_Console","Monitor","oracle.security.jps.service.policystore.ApplicationRole","SBMonitor")
    #grantAppRole("Service_Bus_Console","Tester","weblogic.security.principal.WLSUserImpl","weblogic")
    try:
      print('Grant OSB Role: '+osbAppRole+' to WebLogic Group: '+wlsGroup)
      grantAppRole("Service_Bus_Console",osbAppRole,"weblogic.security.principal.WLSGroupImpl",wlsGroup)
      print('Grant Succeeded')
    except:
      print('Failed to grant role '+ osbAppRole+' to '+wlsGroup+'.')
      print('Check if role not already granted.') 

Add this to the createUsers.py script in my previous article.
Then add the following call to add a role to a group:
    #
    # Grant AppRole
    grantOSBAppRoleToWlsGroup(grpOsbDevOSBAppRole, grpOsbDevName)

This needs the following property in the property file:
# Possible App Roles: MiddlewareAdministrator, Developer, Composer, Deployer, Tester, Monitor, MiddlewareOperator, ApplicationOperator, APICurator
grpOsbDevOSBAppRole=Developer

In the comments I provided the possible values that are described in the docs (see again my previous article).

A description of the grantAppRole can be found here in the 11g docs.

The possible parameters of the function are:


Argument
Definition
appStripeSpecifies an application stripe. For SB12c it is: 'Service_Bus_Console'. You can get it from the pop-list in the EM, WebLogic Domain Menu->Security->Application Roles->Application Stripes Pull Down. (See here).
appRoleNameSpecifies a role name. For SB12c this is one of: MiddlewareAdministrator, Developer, Composer, Deployer, Tester, Monitor, MiddlewareOperator, ApplicationOperator, APICurator
principalClass Specifies the fully qualified name of a class. Unclear from the docs what to use. But I found (actually on a BI-EE blog):
  • For WebLogic users: weblogic.security.principal.WLSUserImpl
  • For WebLogic groups: weblogic.security.principal.WLSGroupImpl
  • Apparently for Application Roles: oracle.security.jps.service.policystore.ApplicationRole
principalNameSpecifies the principal name.


With this you can enhance the createUsers script to create actual ServiceBus users. For SOASuite or other components you can get the Application Specific Roles by querying the Application Stripe in EM.

Monday, 11 July 2016

Reset your Datasources

In most SOASuite and Oracle ServiceBus projects the Database Adapter is used. And often it is used to invoke PL/Sql functions and procedures. Actually, it's my favorite interaction method with the database, since the re-entrancy of the database adapter wizard is best there. To do a re-entrant update of a select or DML operation when for instance a column is added, is simply put often quite problematic.

But the thing is with Pl/Sql that when you update a pl/sql package the package state is altered and when calling it from another session you'll get a 'ORA-04068: existing state of packages has been discarded' error. And this is will occur for every connection in the pool of your datasource.

The solution is to reset the datasource. This can be done easily in the WebLogic Administration Console (http://adminserver:port/console). But nowadays you can do it as easily in Enterprise Manager Fusion Middleware Control. This can be quite convenient for developers since often you have EM already open because of your SOASuite tests.

To do this open the Weblogic Domain menu and select the option 'JDBC DataSources':
 Select the DataSource you want to reset, for the example I choose the 'EDNDataSource', but probably you'd not do this for one, but for a custom DataSource:

 Click the Control tab, select the DataSource in the table and click Reset:

Reset will drive WebLogic to recreate all the connections in the DataSource. This prevents popping up the message multiple times.

The functionality in Configuring, Monitoring and Controlling the Datasource  is similar as in the WebLogic Admin console. Only the layout is a little different.

Thursday, 7 July 2016

Create Weblogic users for ServiceBus

At one of my customers there was the question of creating users that needed to log on to EM (Fusion MiddleWare Control) and Service bus console to be able  to deploy SB en WLS Artefacts (queues, datasources etc.) on the Dev and Test environment. And to be able to do some monitoring on Acceptance. Further more they still used weblogic as the only, shared, administrator user. For the latter Oracle recommends to create at least one other user, to prevent you from an accidental admin-lockout. So I'd create named admin-users for each administrator.

Since there were several users to provision on several systems, it would be convenient to have a script to create the users and the particular groups.

As for the Roles there we need to differentiate to WebLogic default roles and and groups, and Service Bus roles.

To be able to log on to the EM, WLS Console and/or Servicebus the user at least needs the WLS Monitor role, which is provided using the Monitors group. But to be able to start and stop servers (that the developers need/want on dev and at this customer also test) you need the Operators group. To be able to create WLS Artefacts, the user need to be in the Deployers group. More on that you can read in chapter '6 Users, Groups, And Security Roles' in the document 'Securing Resources Using Roles and Policies for Oracle WebLogic Server' (12.2.1).

The Servicebus Application Specific Roles are described in the paragraph '11.1.3 Roles' within chapter '11.1 Understanding Oracle Service Bus Application Security' of the document 'Administering Oracle Service Bus'. How to add those to weblogic users and groups is quite clearly described in paragraph '19.1.3.3 Adding a Product-Specific Administration Role to the Enterprise Deployment Administration Group' of the 'Enterprise Deployment Guide for Oracle SOA Suite' (12.2.1), so I'm not going to copy that.

In the following script first administrator-users are created and added to the administrators group.
For every user group that is created (Administrators, OSB Developers  and OSB Testers), the property file (example is provided later) contains three comma seperated lists for the usernames, passwors and the user descriptions. So you can provide as many as you want, provided that the order in the passwords and description lists match the order in the user list. Of course if you have many users, you should consider implementing an LDAP Directory with WebLogic.
For each list of users the script loops over the list and fetches based on an incremented idx-variable the accompanying password and description. It creates the user and adds it as a member to the particular group.

After the administrator-users, the OSB Developers group is created, and for the Dev environment it is added to the WebLogic groups Operators and Deployers. It is done in a loop, based on a list of WebLogic groups this group should be a member of. In EM the group is added to the OSB Application Specific role 'Developer'. I haven't searched for a wls example to do that, but it is a environment specific small activity so I kept that manual.
After the OSB Developers group, the OSB Developer users are created.

Lastly in the same way the OSB Tester group and users are created. The Tester group is only added to the Weblogic Monitors group, and in EM added to the OSB Application Specific role 'Tester'.

So here's the createUsers.py script:
#############################################################################
# Create WebLogic Users and groups
#
# @author Martien van den Akker, Darwin-IT Professionals
# @version 1.1, 2016-07-06
#
#############################################################################
# Modify these values as necessary
import sys, traceback
scriptName = sys.argv[0]
#
#
lineSeperator='__________________________________________________________________________________'
#
#
def usage():
  print 'Call script as: '
  print 'Windows: wlst.cmd '+scriptName+' -loadProperties localhost.properties'
  print 'Linux: wlst.sh '+scriptName+' -loadProperties environment.properties'
  print 'Property file should contain the following properties: '
  print "adminUrl=localhost:7001"
  print "adminUser=weblogic"
  print "adminPwd=welcome1"
#
#
def connectToadminServer(adminUrl, adminServerName):
  try:
    print(lineSeperator)
    print('Try to connect to the AdminServer')
    try:
      connect(userConfigFile=usrCfgFile, userKeyFile=usrKeyFile, url=adminUrl)
    except NameError, e:
      print('Apparently user config properties usrCfgFile and usrKeyFile not set.')
      print('Try to connect to the AdminServer adminUser and adminPwd properties')
      connect(adminUser, adminPwd, adminUrl)
  except WLSTException:
    message='Apparently AdminServer not Started!'
    print (message)
    raise Exception(message)
#
#
def getRealm(name=None):
  cd('/')
  if name == None:
    realm = cmo.getSecurityConfiguration().getDefaultRealm()
  else:
    realm = cmo.getSecurityConfiguration().lookupRealm(name)
  return realm
#
#
def getAuthenticator(realm, name=None):
  if name == None:
    authenticator = realm.lookupAuthenticationProvider('DefaultAuthenticator')
  else:
    authenticator = realm.lookupAuthenticationProvider(name)
  return authenticator  
#
#
def createUser(authenticator, userName, password, description):
  print ("Creating user " + userName)
  if authenticator.userExists(userName):
    print ("User "+userName+" already exists.")
  else:
    print ("User "+userName+" does not exist.")
    authenticator.createUser(userName, password, description)
    print("User "+userName+" created with password "+password+".")
#
#
def createGroup(authenticator, groupName, description):
  print ("Creating group " + groupName)
  if authenticator.groupExists(groupName):
    print ("Group "+groupName+" already exists.")
  else:
    print ("Group "+groupName+" does not exist.")
    authenticator.createGroup(groupName, description)
    print("Group "+groupName+" created.")
#
#
def addMember2Group(authenticator, groupName, memberName):
  print ("Adding member "+memberName+" to group " + groupName)
  if authenticator.isMember(groupName,memberName,true) == 0:
    print ("Member "+memberName+" not yet member of the group "+groupName+".")
    authenticator.addMemberToGroup(groupName, memberName)
    print ("Member "+memberName+" added to the group "+groupName+".")
  else:
    print ("Member "+memberName+" already member of the group "+groupName+".")
#
#
def main():
  try:
    print (lineSeperator)
    print ('Start Osb Cluster')
    print (lineSeperator)
    print('\nConnect to AdminServer ')
    connectToadminServer(adminUrl, adminServerName)
    #
    #Create Users
    # Get Realm and Authenticator
    realm = getRealm()
    authenticator = getAuthenticator(realm)
    # Administrators
    print('\nCreate Administrator users')
    administratorList=administrators.split(',')
    administratorDescrList=administratorsDesc.split(',')
    administratorPasswordList=administratorPasswords.split(',')
    #
    idx=0
    for administrator in administratorList:
      administratorDesc=administratorDescrList[idx]
      administratorPassword=administratorPasswordList[idx]
      print(str(idx)+': Process administrator user '+administrator+' with description '+administratorDesc)
      createUser(authenticator, administrator, administratorPassword, administratorDesc)
      addMember2Group(authenticator, 'administrators', administrator)
      idx=idx+1
    #
    # OSB Developers
    print('\nCreate group '+grpOsbDevName)
    createGroup(authenticator, grpOsbDevName, grpOsbDevDesc)
    grpOsbDevWlsGrpList=grpOsbDevWlsGrps.split(',')
    idx=0
    for wlsGroup in grpOsbDevWlsGrpList:
      print(str(idx)+': Add '+grpOsbDevName+' to '+wlsGroup)
      addMember2Group(authenticator, wlsGroup, grpOsbDevName)
      idx=idx+1      
    #
    osbDeveloperList=osbDevelopers.split(',')
    osbDeveloperDescrList=osbDeveloperDescriptions.split(',')
    osbDeveloperPasswordList=osbDeveloperPasswords.split(',')
    #
    print('Create OSB Developer users')
    idx=0
    for osbDeveloper in osbDeveloperList:
      osbDeveloperDesc=osbDeveloperDescrList[idx]
      osbDeveloperPassword=osbDeveloperPasswordList[idx]
      print(str(idx)+': Process OSB Developer user '+osbDeveloper+' with description '+osbDeveloperDesc)
      createUser(authenticator, osbDeveloper, osbDeveloperPassword, osbDeveloperDesc)
      addMember2Group(authenticator, grpOsbDevName, osbDeveloper)
      idx=idx+1
    #
    # OSB Testers
    print('\nCreate group '+grpOsbTestName)
    createGroup(authenticator, grpOsbTestName, grpOsbTestDesc)
    grpOsbTestWlsGrpList=grpOsbTestWlsGrps.split(',')
    idx=0
    for wlsGroup in grpOsbTestWlsGrpList:
      print(str(idx)+': Add '+grpOsbTestName+' to '+wlsGroup)
      addMember2Group(authenticator, wlsGroup, grpOsbTestName)
      idx=idx+1
    #
    osbTesterList=osbTesters.split(',')
    osbTesterDescrList=osbTesterDescriptions.split(',')
    osbTesterPasswordList=osbTesterPasswords.split(',')
    #
    print('Create OSB Tester users')
    idx=0
    for osbTester in osbTesterList:
      osbTesterDesc=osbTesterDescrList[idx]
      osbTesterPassword=osbTesterPasswordList[idx]
      print(str(idx)+': Process OSB Tester user '+osbTester+' with description '+osbTesterDesc)
      createUser(authenticator, osbTester, osbTesterPassword, osbTesterDesc)
      addMember2Group(authenticator, grpOsbTestName, osbTester)
      idx=idx+1
    #
    print('\nExiting...')
    exit()
  except NameError, e:
    print('Apparently properties not set.')
    print "Please check the property: ", sys.exc_info()[0], sys.exc_info()[1]
    usage()
  except:
    apply(traceback.print_exception, sys.exc_info())
    exit(exitcode=1)
#call main()
main()
exit()

And here an example of the property file:
#############################################################################
# Properties for Creating WLS Users
#
# @author Martien van den Akker, Darwin-IT Professionals
# @version 1.0, 2016-07-06
#
#############################################################################
#
# Properties for AdminServer
adminServerName=Adminserver
adminUrl=lxoosb301:7001
# AdminUser
adminUser=weblogic
adminPwd=wlsadmin_O3
#
defaultPassword=welkom123
#
grpOsbDevName=OSBDevelopers
grpOsbDevDesc=OSB Developers
grpOsbDevWlsGrps=Deployers,Operators
#
osbDevelopers=sjaak,maarten
osbDeveloperDescriptions=Sjaak with a Lastname - OSB Developer,Maarten from another father - OSB Developer
osbDeveloperPasswords=sjaak123,maarten456
#
grpOsbTestName=OSBTesters
grpOsbTestDesc=OSB Testers
grpOsbTestWlsGrps=Monitors
#
osbTesters=wim
osbTesterDescriptions=Wim You know - OSBTester
osbTesterPasswords=wimrt789
#
administrators=hans,martien
administratorsDesc=Hans the Admin,Martien van den Akker (extern)
administratorPasswords=hans123,martien456

As you can see the descriptions may have spaces and dashes and other characters in it. But certainly no comma's (','), since that breaks the list. Often the description is used to provide a full name.
Also it contains a references to the admin server and the admin username/passsword. So you need to adapt this part of the property file for each environment.
In a later past I'll show how to create user key files to use encrypted administrator passwords. So after creating the users, remove this file from your system.
To start it you can use the following shell script, or get the running wlst command from:
#!/bin/bash
#############################################################################
# Create users
#
# @author Martien van den Akker, Darwin-IT Professionals
# @version 2.1, 2016-07-06
#
#############################################################################
#  
. fmw12c_env.sh
echo
echo Create Users
wlst.sh ./createUsers.py -loadProperties fmw.properties

Rename the fmw.properties reference to the file you named the property file created based on the property file example above.

That (as my other scripts) needs a fmw12c_env.sh script like:
#!/bin/bash
echo set Fusion MiddleWare 12cR2 environment
export FMW_HOME=/ontw/u01/app/oracle/product/fmw12c2
#
echo call setWLSEnv.sh
. $FMW_HOME/wlserver/server/bin/setWLSEnv.sh
export PATH=$FMW_HOME/oracle_common/common/bin:$WL_HOME/common/bin/:$WL_HOME/server/bin:$PATH


Wednesday, 6 July 2016

OSB 12c Logging part 2

Two weeks ago, I wrote about how to set the log level voor SB Pipelines (12c) to be able to see the logging of the Log activity in the WebLogic Server logs.

Today I encountered that for a developer at my customer the complete oracle.osb.logging.pipeline logger was missing in the log-configuration. So setting the level from EM (Fusion Middleware Control) following the article above is a little hard.

I could not find why in that case the logger was missing. But I did find a simple solution.
In the paragraph '7.1.4 ODL Log Configuration' of the Administering Oracle Service Bus documentation, I found that  you can change the logging via the EM, wlst and the logging.xml file. This file can be found in ${osb.domain.home}/config/fmwconfig/servers/${osbserver.name}, eg. 'c:\Data\JDeveloper\SOA\system12.2.1.0.42.151011.0031\DefaultDomain\config\fmwconfig\servers\DefaultServer\'.

Go to the end of the file:
   ...
  <logger name='com.sun.xml.ws' level='WARNING' useParentHandlers='true'/>
 </loggers>
</logging_configuration>

Copy the last logger and rename it to create an entry for the oracle.osb.logging.pipeline logger:
   ...
  <logger name='com.sun.xml.ws' level='WARNING' useParentHandlers='true'/>
  <logger name='oracle.osb.logging.pipeline' level='TRACE:16' />
 </loggers>
</logging_configuration>

Set the level and remove the useParentHandlers attribute.
Restart your server and then you should find the option in the EM OSB Log Configuration. If you have multiple OSB servers you'd probably need to update this change for every osb server, since the logging.xml resides in a server specific sub-folder. I haven't tried it to add it for one server and change it to see if it is automatically added to the other server. Would be a nice experiment.

Monday, 4 July 2016

SOA Server (12c) not startable from script-created domain.

If you're a regular reader of this blog, you've noticed that I've been busy with creating soasuite/osb installations with weblogic domains in a scripted way.

I also optimized my start and stop scripts, that I'll post soon. All this work keeps me from writing on my BPEL book, so for those who are interested in my next episode, I hope you're patient.

But to get to that, it would be nice to have a running SOA Server in my automatically created domain. And unfortunately, that doesn't get up in running mode. Somewhere in the process it fails to start services and switches over to ADMIN mode.

I did some investigation and ran in to the following exception in the server log:

####<Jul 4, 2016 3:30:49 AM EDT> <Error> <Deployer> <darlin-vce-db.darwin-it.local> <SoaServer1> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <f2c434e6-7b67-4a8c-9e2f-8b886152cced-0000000a> <1467617449212> <[severity-value: 8] [rid: 0] [partition-id: 0] [partition-name: DOMAIN] > <BEA-149205> <Failed to initialize the application "OracleBPMBACServerApp" due to error weblogic.management.DeploymentException: Could not find OSGi framework with name bac-svnserver-osgi-framework
weblogic.management.DeploymentException: Could not find OSGi framework with name bac-svnserver-osgi-framework
 at weblogic.osgi.internal.OSGiAppDeploymentExtension.deployBundlesIntoFramework(OSGiAppDeploymentExtension.java:126)
 at weblogic.osgi.internal.OSGiAppDeploymentExtension.prepare(OSGiAppDeploymentExtension.java:245)
 at weblogic.application.internal.flow.AppDeploymentExtensionFlow.prepare(AppDeploymentExtensionFlow.java:25)
 at weblogic.application.internal.BaseDeployment$1.next(BaseDeployment.java:730)
 at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:45)
 at weblogic.application.internal.BaseDeployment.prepare(BaseDeployment.java:242)
 at weblogic.application.internal.EarDeployment.prepare(EarDeployment.java:67)
...

Apparently there was a problem with the OSGi Framework with the name 'bac-svnserver-osgi-framework' that couldn't be found.

OSGi in a domain with both OSB and BPM was a problem in 12cR1. Several blogs are written about that (like this and this one). However, the problem in those blogs is solved soon after the release of 12cR1. In my case something different is happening.

I took a look and it turns out that the 'bac-svnserver-osgi-framework' was not targetted to the SOAServer, although it was targetted to the AdminServer. To check that, navigate to Services->OSGi Frameworks in the Domain Structure:

Here you see the result of my retargetting. If it does not show the SoaCluster or SOA Server, then click on 'bac-svnserver-osgi-framework' and click on the Targets  tab:

At least check the SoaCluster or, if no cluster the SoaServer1. I unchecked the AdminServer because in the earlier posts unchecking the AdminServer was one proposed solution to resolve the OSB-BPM SharedDomain URL issue. But I'm not sure it's needed.

Click Save and activate the changes and, in my case at least, the SoaServer should be startable.


Friday, 1 July 2016

Rename your Weblogic 12c AdminServer

At one of my customers we create Service Bus Weblogic Domains using a script, driven by a property file. But in one of the environments we encountered that the AdminServer was accidently called 'Adminserver', with a lower-case 's'. Now this is a very minor issue, but the administrator would like to have it fixed, since it is an anomaly regarding with other environments.

This week I got to implement my start-stop scripts (which I will publish later) and so bumbed into this naming fault again.

Renaming it turns out to be walk in the park. So let me show you how I did it. Most of the steps could easily be done in a WLST script, but I trust this is not something you would do on a regular basis, so we do it just in off-line commandline mode.

Before doing anything from the steps below, first shutdown the complete domain, all the weblogic servers, including the AdminServer. And I should advice: backup your domain. This can easily be done by zipping the domain folder.

Then set the fmw environment, that is most conveniently done using a script. The one I always create on a new environment is fmw12c_env.sh:

#!/bin/bash
echo set Fusion MiddleWare 12cR2 environment
export FMW_HOME=/u01/app/oracle/fmw12c2

export SOA_HOME=$FMW_HOME/soa
export OSB_HOME=$FMW_HOME/osb
export MFT_HOME=$FMW_HOME/mft
#
echo call setWLSEnv.sh
. $FMW_HOME/wlserver/server/bin/setWLSEnv.sh
export PATH=$FMW_HOME/oracle_common/common/bin:$WL_HOME/common/bin/:$WL_HOME/server/bin:$PATH

Under Linux you should run this as:
$ . ./fm12c_env.sh

It is important to add the dot in front of the command, to have the settings exported to the calling session. I trust that if you're on windows, you'd be able to create a .bat/.cmd file out of this.

The script put's wlst.sh/.cmd in the path. Start it, which brings you to a prompt like:
wls:/offline> 

In the offline mode, read the domain first with:
wls:/offline> readDomain('/u01/app/work/domains/osb_domain')
Where '/u01/app/work/domains/osb_domain' is the path to the domain.
Navigate to the Servers node:
wls:/offline/osbo3_domain>cd ('/Servers')
wls:/offline/osbo3_domain/Server>ls()
drw-   Adminserver
drw-   osb_server1
Then navigate to the Adminserver (you could have done that immediately, but you might want to check on your servers first):
wls:/offline/osbo3_domain/Server>cd ('Adminserver')

For the wlst novice: you might have discovered by now that we navigate through (cd()) and introspect (ls())the MBean-hierarchy using filesystem-related commands. The current folder is actually the current MBean at hand, also called the 'Current Managed Object', in short 'cmo'.
So now we're at it, change its name, for instance:
wls:/offline/osbo3_domain/Server/Adminserver>cmo.setName('AdminServer')
To have this change effect you need to write/save/update the domain:
wls:/offline/osbo3_domain/Server/Adminserver>updateDomain()

After that you can quit wlst using the 'exit()' command.

There is still one little issue to solve, before being able to start the AdminServer and the rest of the domain.

In most cases the nodemanager uses the startWebLogic.sh command to start the domain. This one calls the setDomainEnv.sh/.cmd script.

When no Servername is provided as the start parameter, the AdminServer is assumed to be started.
This is evaluated in the setDomainEnv.sh/.cmd in the following lines:
if [ "${SERVER_NAME}" = "" ] ; then
        SERVER_NAME="Adminserver"
        export SERVER_NAME
fi

So edit the file, locate the lines and change the line 'SERVER_NAME="Adminserver"' to 'SERVER_NAME="AdminServer"' (or the name you used in change the server to).

In this same file, setDomainEnv.sh/.cmd, you might want to disable the start of the Derby Java Database server.
Locate the lines
# Set DERBY_FLAG, if derby is available.

if [ "${DERBY_FLAG}" = "" ] ; then
        if [ -f ${WL_HOME}/common/derby/lib/derby.jar ] ; then
                DERBY_FLAG="true"
                export DERBY_FLAG
        fi
fi
And add the following lines just before the 'if':
DERBY_FLAG="false"
export DERBY_FLAG

To be able to start the renamed AdminServer you also might want to move the folder named 'security' from the ${DomainHome}/servers/Adminserver folder (the server folder with the previous name) to the corresponding folder with a new name. This allows the renamed server to reuse the boot.properties file. And remove the old folder, or rename the server folder to the new name.

This concludes the renaming-steps. Now you're good to go to startup the domain again.