Contact us: +52 (55) 9172-1478
contacto@spsolutionsmx.net
  • Home
  • Blog
  • Re-associating your SOA Suite domain with Policy Store based on Database SOA Suite 11g

Re-associating your SOA Suite domain with Policy Store based on Database SOA Suite 11g

By default, when you install a Fusion Middleware domain, the Policy Store (part of the Java Platform Service) it is based on files. For sure you remember the system- jazn – data.xml, or the same jps -config.xml.

It is somewhat normal to leave the default settings until the need arises to generate users, connect to an LDAP, etc. Even in a productive environment, Oracle does not suggest (and do not support) this type of configuration.

Especially if you are in a cluster environment where you have a series of distributed machines, depending on the file-based Policy Store, can be risky because if these files are damaged, your WebLogic domain is on risk of being damaged.

There are three options for your Policy Store. This applies to an environment of 11g, and for sure 12c is equivalent, but everything in this article is discussed for 11g . We are also using the example of Oracle SOA Suite, as a component of Fusion Middleware:

1. Based on files. This is the default configuration. These files are the ones that I mentioned at the start of the post. All roles, groups, etc., are based on those files. Whenever you assign a user to a particular group, say the role of Oracle BAM Architect the system- jazn – data.xml file will be affected.

2. Based on BBDD. This is a direct option to use, since at the end the SOA Suite (like almost all the components of Fusion Middleware) requires a database to run. So you no longer have to seek additional database for this setup since you already have it.

3. Based on a LDAP. In 11g it is still mentioned an Oracle Internet Directory (OID), and, for this version, that is exactly the suggestion. Here everything is based on a tree structure inside the OID.

At the end, options 2 and 3 are suitable for production.

Let’s use option No. 2, to illustrate how to make the change.

STEP 1

You must install the OPSS scheme if you did not make it when installing your SOA Suite domain. Then perform the following steps. Execute rcu.sh (or rcu.bat if you are in Windows).

Select the prefix that you have or create a new one. Select the OPPS option (Making click over the images you will be able to see the better):

Reasociando tu dominio de SOA Suite con un Policy Store basado en Base de Datos. SOA Suite 11g.

The window requesting for your password will open:

Reasociando tu dominio de SOA Suite con un Policy Store basado en Base de Datos. SOA Suite 11g.

It will tell you that the required table spaces will be generated. Please consult this with your DBA, since they normally question things such as: size, names, etc. and if this will be a production change it is much better to ask:

Reasociando tu dominio de SOA Suite con un Policy Store basado en Base de Datos. SOA Suite 11g.

Make click in next and you will get a summary:

Reasociando tu dominio de SOA Suite con un Policy Store basado en Base de Datos. SOA Suite 11g.

Make click in Create and it will generate the needed objects:

Reasociando tu dominio de SOA Suite con un Policy Store basado en Base de Datos. SOA Suite 11g.

Finally it will finish and it will provide you with a summary of what has been generated:

Reasociando tu dominio de SOA Suite con un Policy Store basado en Base de Datos. SOA Suite 11g.

After this, please go inside the Weblogic Console of your domain and create a datasource with the following options. It is very important that you take a look to the XA options, since this will not support XA. If you make it, you will have problems for sure:

Reasociando tu dominio de SOA Suite con un Policy Store basado en Base de Datos. SOA Suite 11g.

Select that driver type:

Reasociando tu dominio de SOA Suite con un Policy Store basado en Base de Datos. SOA Suite 11g.

Pay attention to the next options:

Reasociando tu dominio de SOA Suite con un Policy Store basado en Base de Datos. SOA Suite 11g.

When you have created the data source, you should go to the command line, since we will be using the WLST option to make the re-association. You can also make it through Enterprise Manager, but now we will use WLST.

Connect as it is shown in the screen below and execute the command:

reassociateSecurityStore(domain=”soa_domain”, servertype=”DB_ORACLE”,datasourcename=”jdbc/OPSS_DS”, jpsroot=”cn=SecurityStore”, join=”false”)

The join parameter is important and maybe you ask yourself why it comes as false if what we can to do is exactly to associate it to a BBDD. Well, this says that in this repository already exist a Policy Store to which you want to join. In this case, this is not true since we are going to create it now

Reasociando tu dominio de SOA Suite con un Policy Store basado en Base de Datos. SOA Suite 11g.

When it finishes, you will see the following:

Reasociando tu dominio de SOA Suite con un Policy Store basado en Base de Datos. SOA Suite 11g.

Reasociando tu dominio de SOA Suite con un Policy Store basado en Base de Datos. SOA Suite 11g.

Now you have re-associated your domain with a Policy Store based on BBDD. All the management will be based there. The structure and the data will be in the tables that were generated by the OPSS.

The profiling that you have made for your applications (for example, BPM, Composer, BAM, etc.) will also be migrated. You will not only generate the structure on BBDD, but will migrate also the roles associations you have done.

To confirm that this have happened, go into the Enterprise Manager:

Reasociando tu dominio de SOA Suite con un Policy Store basado en Base de Datos. SOA Suite 11g.

This is a very fast process, please take care in making a backup of your domain before doing any changes, but in reality, this change will take you less than an hour.

(NOTE: If you cannot see the images, please click on them and you will see them better).

Connect With Us

facebook
twitter
linkedin
Privacy Policy