SOA 11g: Native IO must be enabled!

On a project working with Sun Solaris the server was very slow. I took 15 minutes to start and executing composites or accesing the "Human Worklist Application" or "Enterprise Manager" took ages.

I saw in both log files of the AdminServer and soa_server1, one small line:

<Native IO Disabled. Using Java IO.>

This line implies that the system will use Java code instead of O/S specific libraries for executing I/O function.

This can be fixed by setting the correct dynamic Libraries; LD_LIBRARY_PATH.

Make sure you set the LD_LIBRARY_PATH in your start scripts of the Admin and managed servers.

Add this in  the start scripts:

LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$FMW_HOME/wlserver_10.3/server/native/solaris/sparc64
export LD_LIBRARY_PATH


This will result in the following line on the log :-)

<Native IO Enabled.>

SQLAuthenticator and Human Worklist Application

Sometimes you need another authentication mechanism to verify the username and password. In WLS the default authenticator is file based and can be accessed via a lightweight LDAP interface. For simple straight forward applications, it is sufficient.

In a SOA environment, when you use the default worklist application, the users must be registered in the Weblogic Server. Legacy applications have there own mechanism of storing user data. In our Oracle world, users and passwords are often stored in tables of the database.

The goal is to re-use this table mechanism in combination with the default Worklist Application. The approach is rather simple, but it is not working.

• Add WebLogic SQLAuthenticator provider in your security realm.

When you have applied this new authenticator, the worklist application can not authenticate the users from the database. You will get an error:

Internal Error in Verification Service for user SKING. lookupUser.
Check the underlying exception and correct the error. If the error  persists, contact Oracle Support Services.                                            

ORABPEL-30504                                                                                                                                             
Internal Error  in Verification Service.

The issue is within the worklist application itself. It only authenticates via LDAP and ignoring the SQLAuthenticator.

We are able to fix this issue. The solution is based on the SOA Samples of the Human Worklfow; "workflow-120-SQLIdentityProvider". You can obtain the examples via Oracle TechNet or via your Oracle Rep.

The solution is as follows and is based on the SQL Authenticator Example of Edwin Biemond.

• Apply the SQL Authenticator in your SOA WLS environment.
• Test if users and groups can be viewed and edited.
• Shutdown the admin server and managed servers.
• Copy the dbprovider.jar to the SOA_DOMAIN/lib directory
• make changes in the SOA FMW  JPS config file:

1. Add a new Identity Store.
2. Add a new Service Instance.
3. Change JpsContext to the new Identity store.

• Start admin and managed servers
• Test the worklist application with database users.

Note: the dbprovider.jar is created with the "workflow-120-SQLIdentityProvider" example. Check the files

• DBUserSearchResponse.java
• DBRolesSearchResponse.java

If they are query the correct tables and columns. If they are not correct, compile and create a new JAR file.

Example of the jps-confix.xml file:

<serviceProviders>
  <!-- New ID provider -->
  <serviceProvider type="IDENTITY_STORE" name="custom.provider" 
class="oracle.security.jps.internal.idstore.generic.GenericIdentityStoreProvider">
     <description>Custom IdStore Provider</description>
  </serviceProvider>
  <!-- EOF New ID provider -->
...
<serviceInstances>
  <!-- NEW Service Instance -->
  <serviceInstance name="idstore.custom" provider="custom.provider" location="dumb">
      <description>Custom Identity Store Service Instance</description>
      <property name="idstore.type"            value="CUSTOM"/>
      <property name="ADF_IM_FACTORY_CLASS"    value="org.sample.providers.db.DBIdentityStoreFactory"/>
      <property name="DB_SERVER_NAME"          value="database.vijfhuizen.local"/>
      <property name="DB_SERVER_PORT"          value="1521"/>
      <property name="DB_DATABASE_NAME"        value="orcl"/>
      <property name="ST_SECURITY_PRINCIPAL"   value="demo"/>
      <property name="ST_SECURITY_CREDENTIALS" value="demo"/>
  </serviceInstance>
  <!-- EOF NEW Service Instance -->
...
<jpsContexts default="default">
  <!-- This is the default JPS context. All the mendatory services and Login Modules must be configured in this default context -->
  <jpsContext name="default">
      <serviceInstanceRef ref="credstore"/>
      <serviceInstanceRef ref="keystore"/>
      <serviceInstanceRef ref="policystore.xml"/>
      <serviceInstanceRef ref="audit"/>
      <serviceInstanceRef ref="idstore.custom"/>
  </jpsContext>

Good luck!

SOA 11g Cloning

Cloning an SOA 11g environment is rather simple. Due to the architecture of the Weblogic application server, you can do this easily. The steps are as follows.

1. Make sure you stopped the Managed Servers and Admin server.
2. Copy the BEA_HOME directory to your target destination.
3. Copy the SOADOMAIN_HOME directory to your target destination.
4. Export the SOA repository from the database.
5. Import the SOA repository in target database.
6. Manually make changes in the SOADOMAIN_HOME/config/config.xml file.
7. Manually make changes in the WLS_HOME/wls_server1/common/nodemanger/* properties.
8. Manually make changes in the SOADOMAIN_HOME/config/jdbc/* datasource file(s) to target database.
9. Make changes in start-up scripts when using WKA in Coherence clustering. 
10. Start servers
11. Check SOAP Server URL and Callback Server URL

1
Make sure that all the WLS servers are stopped in the domain, even the clustered ones. This is to make sure that no caching occurs.

2
Copy the binary tree to another destination. You could install the WLS software-only, but a copy is quicker.

3
Use the tool pack/unpack to copy a complete domain from one destination to another. Alternatively you could copy the complete file tree of your SOA_DOMAIN, including the application directory.

4
Make an export of the SOA repository, make sure you have the rights to export the various SOA schema's such as, MDS, SOA_INFRA etc.

5
Import the exported data. In this case, the SOA schema's must be already there or they will be created during the import. Again, you must have the correct privileges to create schema's and apply the correct grants.

But be ware that the users in the other database need to have to following roles:

select * from dba_role_privs where grantee like 'DEV_%' order by grantee;

GRANTEE        GRANTED_ROLE         
-------------- ---------------------
DEV_SOAINFRA   CONNECT              
DEV_SOAINFRA   RESOURCE             
DEV_SOAINFRA   AQ_USER_ROLE         
DEV_SOAINFRA   AQ_ADMINISTRATOR_ROLE
DEV_SOAINFRA   SELECT_CATALOG_ROLE  

DEV_MDS        RESOURCE             
DEV_MDS        CONNECT              

DEV_ORABAM     CONNECT              
DEV_ORABAM     RESOURCE             

Or more in detail:

select
  lpad(' ', 4*level) || granted_role "User, his roles and privileges"
from
  (
/* 
 * Users
 */ 
    select 
      null     grantee, 
      username granted_role
    from 
      dba_users
    where
      username like 'DEV_%'
/*
 * the roles to roles relations 
 */ 
  union
    select 
      grantee,
      granted_role
    from
      dba_role_privs
  /* THE ROLES TO PRIVILEGE RELATIONS */ 
  union
    select
      grantee,
      privilege
    from
      dba_sys_privs
  )
start with grantee is null
connect by grantee = prior granted_role;

6
Make changes in the config.xml file, to set new hostnames and/or IP addresses for the Admin Server, Managed Servers and node manager (machine)


7
Make changes in the nodemanger comnfiguration. If this is a new server, the nodemanager.properties should be updated. If the cloning is done on the same server, you should change the port number only, or reuse an existing node-manager.

8
Make changes in the JDBC connections. The data-sources for target database updated.

9
If you are using a clusterm verify the coherence properties, such as multicast adresses. If you are using well-known-adresses (WKA) make sure the are updated.

10
Now you are able to start the admin and managed servers.

11
If you are usingf a loadbalancer check SOAP Server URL and Callback Server URL via Enterprise manager. (EM -> SOA-INFRA -> SOA Administration  -> Common Properties)


Note: With this solution you loose existing running processes.