Tuesday, July 27, 2010

Adding a new operation into an existing WSDL of a SOA composite in JDeveloper

The following scenarios are possible during the lifecycle of a service side WSDL in a SOA composite component.

1) Create a new exposed service from scratch in the JDev composite composer.
2) Import an existing WSDL as an exposed service in the composite.
3) Add a new operation into the existing exposed service of a composite component.
4) Drop an existing operation from the exposed service of a composite component.

This tutorial will address scenario #3 where a new operation is required to be added to an existing composite without breaking the existing mediator plan. The task was completed using JDeveloper 11.1.1.3.0.

The steps will take us from the as-is state (call that version 1.0) into the to-be state (version 2.0). At the end, we will have a working composite component that exposes one extra WSDL operation. To the consumer, that will be the only visible change in the versioned service.

This example is based on the simple DEPT and EMP tables in the sample schema SCOTT. The as-is state contain a simple getDepartments operation which returns a department based on the dept number (deptno) passed-in by the consumer.

This paper assumes that you already have all the required tools and servers installed, up and running, ready to accept deployments. You will also need to have the sample schema SCOTT active.

As-is:




 To be:





Steps:

1)      Double click the database adapter on the ‘external reference’ pane.


2)      Click ‘Next’


3)      Keep the JDNI name and click ‘Next’.


4)      Check the ‘Insert Only’ checkbox. This is to tell the database adapter to support the insert operation for the underlying tables (DEPT and EMP). Click ‘Next’.


5)      Click ‘Next’ all the way until you see step 10 and click ‘Finish’. You should see the following updated database adapter diagram in the composite editor.


We need to add an operation to the ‘exposed service’ which is represented by the WSDL definition ‘ScottCRUDOperations’. To achieve this, we need to use the WSDL editor to add new operation and work out the XML schema required by the new operation.

5) Double-click on the ‘ScottCRUDOperations.wsdl’ file in the project explorer.


Layout your editor tabs to look like this and drag the ‘DeptCollection’ element node into your existing portType, in this case it is ‘scottCRUD-ptt’.

You should see a new operation called ‘DeptCollectionOperation’ is added to the porttype. Clean up the operation by renaming it to reflect the actual intended action (insertDepartments), remove the output node as this is an one-way operation. For the sake of simplicity, we will ignore the fault if it happens. It is important to note that at this point of time the operation does not know anything, neither ‘select’ nor ‘insert’. It needs to be ‘wired’ up and we will do that in the Mediator designer/editor.


If you go back to the composite editor now, you will notice a new operation is created.


6) Bring up the Mediator editor by double click on the mediator component diagram.

Note that 1) The existing operation getDepartment is still there. 2) the new operation ‘insertDepartments’ is not there.


7) Refresh the mediator by clicking on the ‘refresh’ icon.


 8) Click ‘OK’. You should see the new operation is added without any route rule.


9) Click the ‘+’ sign and select ‘static routing rule’.


10) Click ‘Service’ as the target type.


11) In the ‘Taget Services’ pick list, expand ‘ScottDatabaseCRUD’ under the ‘References’ node. Select the service named ‘insert’. This will hook the ‘insertDepartments’ operation up with the ‘insert’ service of the database adapter.

The next step is to map the input of ‘insertDepartments’ operation to the ‘insert’ service of the database adapter.

12) Click the transform icon. Choose the ‘Create new mapper file’ option.


13) Click ‘OK’ to see the map editor.




You are done. Save the project, build and deploy. You should see 2 operations available for testing in the EM.

In the next article, I will try to examine the use of SDO (Service Data Object) on tables that do not have a parent-child constraints defined at the database level.

Monday, July 5, 2010

Get rid of the annoying userid and password prompt of the Managed Server start script in SOA Suite 11.1.1.3

The default location of boot.properties in SOA Suite has been changed since 11.1.1.2. The following instructions apply to SOA Suite 11.1.1.3.


To get rid of the username/password prompt during Managed Server startup, place the boot.properties file into the 'security' directory of your managed server. For example, if you managed server name is soa_server1 and your SOA domain is my_soa_domain, then the directory you will place your boot.properties file will be


$MW_HOME/user_projects/domains/my_soa_domain/servers/soa_server1/security


If the 'security' sub-folder does not exist, create it.


The typical content of the boot.properties file will be

username=weblogic
password=welcome123

If you have used different username and password during domain creation, you can specify them here.


Note that upon successful managed server startup, the content of the boot.properties file where you have your username and password in plain text will be encrypted and will look like this

#Mon Jul 05 11:05:31 EST 2010
password={AES}2KPlIqIyN/3Wz8VPawxF+rPyYTBkZ36+mRzgop1VkGU\=
username={AES}QQcQN7tKF7CLFZftjPOq9okkXKSRIfX/BbJVckEv6Xk\=

If you prefer to specify your own location of boot.properties, or even to use a different file name, you can specify them using the JAVA_OPTIONS parameter in the managed server startup script. Open the startManagedServer.sh script located in your $MW_HOME/user_projects/domains/my_soa_domain/bin and add the following lines (preserve the existing JAVA_OPTIONS if there is any).


How-To
- locate the 'export JAVA_OPTIONS' string
- add the following line before the the 'export JAVA_OPTIONS' line
JAVA_OPTIONS="-Dweblogic.system.BootIdentityFile=[your preferred location]/[your preferred properties filename]" ${JAVA_OPTIONS}"
- save the file and exit

Now start the manage server, you will see in the terminal the following java options

/home/kj/Oracle/Middleware/jdk160_18/bin/java -client -Xms512m -Xmx512m -XX:PermSize=128m -XX:MaxPermSize=512m -Dweblogic.Name=soa_server1 -Djava.security.policy=/home/kj/Oracle/Middleware/wlserver_10.3/server/lib/weblogic.policy -Dweblogic.system.BootIdentityFile=/home/kj/Oracle/Middleware/user_projects/domains/soapg_domain/soa_server1_boot.properties -Dweblogic.security.SSL.trustedCAKeyStore=/home/kj/Oracle/Middleware/wlserver_10.3/server/lib/cacerts -Xverify:none -da
...
...
...

The following information on the startup console indicates that the original properties file has been encrypted and stored in the same location as the original plain-text soa_server1_boot.properties.
Storing boot identity in the file: /home/kj/Oracle/Middleware/user_projects/domains/soapg_domain/soa_server1_boot.properties
Open the file soa_server1_boot.properties and you shall see the encypted contents and voila, no more username/password nags on Managed Server startup.

password={AES}2KPlIqIyN/3Wz8VPawxF+rPyYTBkZ36+mRzgop1VkGU\=
username={AES}QQcQN7tKF7CLFZftjPOq9okkXKSRIfX/BbJVckEv6Xk\=

Happy playing.

Cheers.