Easy way to start your WebLogic Servers with the NodeManager in the background

When you work with Fusion Middleware you probably know you need to start the WebLogic Servers with the scripts located in the bin folder of your WebLogic domain and you need to start these servers in the background else these processes will be killed when you log out. On unix you can start these scripts in the background and on Windows you can try to make some Windows services with the service utility of WebLogic, but you need to update the path, classpath and java parameters of this service ( in the registry)  so it matches with the startup script. ( easy to make mistakes and memory changes can't be done from the WebLogic Console )

In this blogpost I will show you how you can start a WebLogic server from WLST in combination with a NodeManager which is started in the background of the server.

The first step is starting the Nodemanager once so the nodemanager.properties file is created. After this you can stop the nodemanager by killing the process
Go to XXX\wlserver_10.3\server\bin and start startNodeManager.cmd

Open the nodemanager.properties in a editor ( located in XXX\wlserver_10.3\common\nodemanager )
For FMW you need to change the StopScriptEnabled property to true, do the same for StartScriptEnabled 


On windows there is a utility to make a service for this nodemanager.
Go to XXX\wlserver_10.3\server\bin and start installNodeMgrSvc.cmd

Start the service

To automatically start a WebLogic Server and not prompted for a username / password  you need to create a boot.properties with username and password and put this in every server folder.

Start startWebLogic.cmd , located in the bin folder of your domain and when it is started then you can shut it down. Do the same for all the Managed Servers. start startManagedWebLogic.cmd xxxx, where xxxx is the name of the managed servers.

Go to XXX\domains\soa_domain\servers and create in every server folder a new folder called security
and create a boot.properties file and with the following content
username=weblogic
password=yourpassword

put this file in every security folder.

Next step is to set the nodemanager username and password
Start your WebLogic AdminServer
Go to the WebLogic Console, Domain and then open the Security tab

 Click on the Advanced link and set the nodemanager username and password

Activate the changes and shutdown the AdminServer

Now you try to start the AdminServer with WLST which connects to the NodeManager


Start XXX\wlserver_10.3\common\bin\wlst.cmd
you will see wls:/offline>

Connect to the NodeManager by using nmConnect
nmConnect('weblogic','yourpassword','localhost','5556','your_domain','C:/XXX/user_projects/domains/your_domain','ssl')
You need to see the  following Successfully Connected to Node Manager.

start the AdminServer
nmStart('AdminServer')

Ask the status of the AdminServer
nmServerStatus('AdminServer')

Stop the AdminServer
nmKill('AdminServer')

disconnect from the nodemanager
nmDisconnect()

Now you can make some cmd and WLST scripts

first create a start WLST script, called startDomain.wlst with the following content
nmConnect('weblogic','yourpassword','localhost','5556','wls_domain','C:/XXX/user_projects/domains/wls_domain','ssl')
nmStart('AdminServer')

nmStart('soa_server1')

nmDisconnect()

and a cmd script startDomain.cmd
call XXX\wlserver_10.3\common\bin\wlst.cmd startDomain.wlst


Now you have a script what you can add to windows task schedular or an other utility

Test your services with AIA CAVS

Composite Application Validation System (CAVS) is part of the Application Integration Architecture Foundation Pack and with CAVS you can test your SOA Composites like SOAPUI or the SOA Test Suite. SOAPUI can test your composite services and it can mock an other service but you need to redeploy some composites to override the endpoints ( so it uses the mocked services endpoints ). The SOA Test Suite is also Ok but is focused to 1 composite. An AIA Process usually contains many composites. So for AIA you need a Test framework who can send a request and can simulate some Composite adapter references services and without redeploying any composites. CAVS can do this for you.
In every Application Business Connector Service (ABCS) of your AIA Process you can do a redirect to a simulator. In this blogpost I will show you how this works. I start with a simple test of a service, grouping some tests together, simulate a service and combine tests and simulators with CAVS routing.

First we start with a simple Test of a SOA Composite Service.
Go the AIA Homepage and press the go button in the Composite Application Validation System window.

Test definition

 In the definitions tab you can see your already defined tests and simulators. Press the Create Test button.

Provide the details. Add the endpoint of the Service you want to test. With Get Operations you can select an operation. To generate a test message press Get Messages.

Add a request between the cavs:CAVSRequestInput_1 element, you can add more then one request. Add a  cavs:CAVSRequestInput_2 element etc.

Provide the matching Response messages in the matching cavs:CAVSResponseOutput_X element.
Important press Generate Xpath so it will generate the validation rules for this test.

 Provide all the namespaces you use in this test.

When you pressed Generate Xpath on the response window you can see all the validations rules ( these based on the response message)  You can add your own.

 You are ready to test your service. Select your test and press Execute.

 In the instance tab you can see the result.

Group Definition
With a Group Definition you can combine test definitions to one group test
Assign some test defintions to this group definition.

You can execute the group definition and look at the instances tab for the results.

Simulation Definition
With a simulation you can for example emulate an reference adapter service of a Provider ABCS. To make an simulator go to the definition tab and press the create simulator button. Provide the values

Add the expected request messages you can receive in this simulator, start with cavs:CAVSRequestInput_1, you can add more expected messages use the right cavs:CAVSRequestInput_X element. Press Generate Xpath for the validation entries.

 Provide the response messages of this simulator.

 Provide the namespaces.

When you pressed Generate Xpath on the request messages then you will find some Xpath validation entries. Very important to provide the node key on every request message so CAVS can detect the right request message and give back the matching response. In my case 122 is the unique identifier.

The simulator part is finished, now you can assign this simulator to a ABCS.

When you create an ABCS with the JDeveloper AIA service constructor, it will create a AIAServiceConfigurationProperties.xml file. This file contains the endpoint url's and if it needs to route the reference to a CAVS simulator.

The AIA deployment framework will add this AIAServiceConfigurationProperties to the AIAConfigurationProperties.xml file  ( located in AIA_Home\aia_instances\AIA_Instance\AIAMetaData\config )

and also located in the MDS in the config folder

To route every request to a simulator you need to go the AIA homepage and press the Go button of the setup  window. Go the AIA Configuration Tab.

 Press add on the ABCS you want to add a simulator to it and select a simulator

 Enable the Route To CAVS option

When you open the AIAConfigurationProperties.xml you can see that the ABCS properties are changed

The changed ABCS entry.

The last part is to combine Testing and Simulation by making an Routing Setup.


Routing Setup
In a Routing Setup you can add particular simulation to one or  more ABCS and use this in a test definition.
Create a Routing Setup

 Add a simulator to the ABCS.

 And open the Test definition and lookup the Routing Setup

This will set the simulator on the ABCS's before the test is executed.

That's all and hope this gives you a quickstart in the AIA CAVS tool.

Set the Initial Focus on a component in a Page or a Fragment

In ADF 11g you can use the initialFocusId property of the af:document component to set the input focus on a UIComponent. On the UIComponent you need to set id property and set the clientComponent property to true. And use this id in the initialFocusId property of the af:document component which is only located in a ADF Page. This is not so hard to do, but sometimes it can be tricky to find the id of a component when you use regions ( Bounded Task Flows ). To solve this you can use the developer tool of Google Chrome or the Firebug plugin of  Mozilla FireFox. Select the UIComponent and take a look at this id, you can remove the ::content part.

To set the focus on an UIComponent in a dynamic Region can be hard because this id of the component is not always the same. It depends which Task Flow you open first ( sometimes it is region1:1:input1 or region1:2:input1 ) . And the second problem you have that you need to use some javascript to set the focus.
The solution is to lookup the region UIComponent and try to find the UIComponent from there, get the clientId and use this value.

Here are some screenshot of the possible scenarios.
Set the focus on the Label 2 item, this is in the ADF page.

Same page but now I set the focus on the DepartmentName in the Department Dynamic Region.

New page but with a static Employee Region.

Example page with the af:document and initialFocusId property set on a managed bean
The managed bean which controls the focus
Here is the example workspace