Implementing SOA projects is not only designing processes and implementing them with Oracle SOA with BPEL, ESB or Human Workflow. In general there are still data-entry screens to be designed and maintained.
From the past customers were using 4GL tools, such as Oracle Designer/Forms tools to generate the data-entry screens. Nowadays, we are using tools such as Oracle ADF Faces to do the same.
I often hear, how does this fit in a SOA Architecture? For Forms/Designer applications there are migration paths to go to a web oriented approach with Oracle ADF Faces and JHeadstart. Applications that stay on the traditional technology stack, can implement another approach.
Customers that are already using or have migrated to this Oracle ADF technology stack must only implement SOA. It sounds simple but some work has to be done. There is a way to use JHeadstart to implement Oracle SOA Webservices (BPEL/ESB) or the Human Worflow into the web application. A nice article on this issue is written on the JHeadstart Blog.
The trick is as follows. With JDeveloper, create a Java wrapper arround your web services or use the Workflow API. With these java classes you create an Oracle ADF view object. This view object can be used in Oracle ADF, using drag and drop to create your screens or use JHeadstart to generate the screens.
Friday, April 27, 2007
Thursday, April 19, 2007
CDM Ruleframe and BPEL / ESB
What is wrong with technology that is working for ages without any troubles. Basically nothing. The disadvantage is that old-fashioned technology is passed by the latest and the greatest. For example SOA and Oracle CDM Ruleframe.
Nothing is wrong with CDM Ruleframe; it's stable, logical, sits in the database and based on good-old PL/SQL.
SOA is hot, using the newest technologies as SOAP, web services, BPEL, Rules, ESB etc.
But how do you combine them? Well that's look easy, but some issues to care about.
When you use CDM Ruleframe the business rules are defined on table level. The rules are fired at once when a user does a DML on the table and commits. CDM Ruleframe will create a list of erros that does not apply to the business rules. It will create a PL/SQL table with all CDM rules that have been failed. These stacked errors should be send back to the client that was initiating the database request.
Now comes the point with SOA. In BPEL or ESB it uses the database adapter to access the Oracle database. This goes over JDBC. If an error occurs it is catch as an exception. In the exception you get the oracle error, for example ORA-20998 and an error message text. In this message text, some text is related to CDM Ruleframe. But not all the business rules are mentioned. It is up to the BPEL instance to catch the error and parse the message text to obtain the error.
A solution for this is as follows. When you want to access the database for query only, use the normal select approach. When you do an update, delete or insert call a PL/SQL package to perform the appropriate action. In this PL/SQL package you can catch the exception and collect the CDM Ruleframe errors and descriptions. This collection is formatted as an XML string in the error message text. The BPEL or ESB instance can now catch the specific oracle eroror, for example ORA-20998, and get error message text, that can be parsed as XML.
Note that the error, in XML format, send back from the Database, can be picked up via the RemoteFault exception. The error message is in the summary element. The only issue is, that is wrapped in a string. A message"Exception occurred" is put in front of the XML message and a string is appended. This can be solved by using the substring-before() and substring-after() to extract the XML result.
Nothing is wrong with CDM Ruleframe; it's stable, logical, sits in the database and based on good-old PL/SQL.
SOA is hot, using the newest technologies as SOAP, web services, BPEL, Rules, ESB etc.
But how do you combine them? Well that's look easy, but some issues to care about.
When you use CDM Ruleframe the business rules are defined on table level. The rules are fired at once when a user does a DML on the table and commits. CDM Ruleframe will create a list of erros that does not apply to the business rules. It will create a PL/SQL table with all CDM rules that have been failed. These stacked errors should be send back to the client that was initiating the database request.
Now comes the point with SOA. In BPEL or ESB it uses the database adapter to access the Oracle database. This goes over JDBC. If an error occurs it is catch as an exception. In the exception you get the oracle error, for example ORA-20998 and an error message text. In this message text, some text is related to CDM Ruleframe. But not all the business rules are mentioned. It is up to the BPEL instance to catch the error and parse the message text to obtain the error.
A solution for this is as follows. When you want to access the database for query only, use the normal select approach. When you do an update, delete or insert call a PL/SQL package to perform the appropriate action. In this PL/SQL package you can catch the exception and collect the CDM Ruleframe errors and descriptions. This collection is formatted as an XML string in the error message text. The BPEL or ESB instance can now catch the specific oracle eroror, for example ORA-20998, and get error message text, that can be parsed as XML.
Note that the error, in XML format, send back from the Database, can be picked up via the RemoteFault exception. The error message is in the summary element. The only issue is, that is wrapped in a string. A message"Exception occurred" is put in front of the XML message and a string is appended. This can be solved by using the substring-before() and substring-after() to extract the XML result.
Wednesday, April 04, 2007
Patches, Patching how to get the SOA Suite Working
A new patchset is out on top of 10.1.3.3.0, 10.1.3.3.1! You can obtain it from metalink.oracle.com as patch numer 6492514.
Note: At last it is there the patch 10.1.3.3! You can obtain it from metalink.oracle.com as patch numer 6148874.
The current version of the Oracle SOA Suite, release 10.1.3.1.0 does install very easy. Alsmost out of the box and you ar eup and running. But, as you start working you will found out that not everything is working as expected. Therefore you must install some patches.
The patches can be obtained from Oracle Metalink, login and click on the tab patches and do an advanced search. Select the product BPEL.
You will found that more that patches are available. So which patch must I install? This is a difficult question. Some patches can not be installed while they are in conflict with others. While other patches contains a set of other patches. So how do you known which patches you need. This is hard to tell. Depeding on your requirement some patches are easy found, some not :-)
Here is a list of patches I use to install at customer projects. It is based on my own expierence, and are related to projects that are based on Advannced Queueing (AQ), Database access (tables, PL/SQL) and files.
Before you install the BPEL patches. You must install patch number "2617419". This patch is a patch for the tool "opatch", that you are using to install the patches. This patch must be unzipped under the $ORACLE_HOME directory.
The list of patches I use:
There is an patchset out for the application server to upgrade to 10.1.3.2. This patch is named "Oracle Application Server Release 3 (10.1.3) Patch Set 2 (10.1.3.2.0)" and can be downloaded from Oracle Metalink. The number of this patchset is 5906151. I applied it on my SOA installation, and everything looks working as expected.
The Oracle ESB product has now it's on product in the patches list of Metalink:
Search for "Product or Product Family" = "Oracle Enterprise Service Bus (oesb)"
Note: At last it is there the patch 10.1.3.3! You can obtain it from metalink.oracle.com as patch numer 6148874.
Marc
Note: At last it is there the patch 10.1.3.3! You can obtain it from metalink.oracle.com as patch numer 6148874.
The current version of the Oracle SOA Suite, release 10.1.3.1.0 does install very easy. Alsmost out of the box and you ar eup and running. But, as you start working you will found out that not everything is working as expected. Therefore you must install some patches.
The patches can be obtained from Oracle Metalink, login and click on the tab patches and do an advanced search. Select the product BPEL.
You will found that more that patches are available. So which patch must I install? This is a difficult question. Some patches can not be installed while they are in conflict with others. While other patches contains a set of other patches. So how do you known which patches you need. This is hard to tell. Depeding on your requirement some patches are easy found, some not :-)
Here is a list of patches I use to install at customer projects. It is based on my own expierence, and are related to projects that are based on Advannced Queueing (AQ), Database access (tables, PL/SQL) and files.
Before you install the BPEL patches. You must install patch number "2617419". This patch is a patch for the tool "opatch", that you are using to install the patches. This patch must be unzipped under the $ORACLE_HOME directory.
The list of patches I use:
- 5566761
- 5659094
- 5724766
- 5729652
- 5742242
- 5747361
- 5851215
- 5855005
- 5915792
- 6082941
- 6082193
- 6053708
There is an patchset out for the application server to upgrade to 10.1.3.2. This patch is named "Oracle Application Server Release 3 (10.1.3) Patch Set 2 (10.1.3.2.0)" and can be downloaded from Oracle Metalink. The number of this patchset is 5906151. I applied it on my SOA installation, and everything looks working as expected.
The Oracle ESB product has now it's on product in the patches list of Metalink:
Search for "Product or Product Family" = "Oracle Enterprise Service Bus (oesb)"
Note: At last it is there the patch 10.1.3.3! You can obtain it from metalink.oracle.com as patch numer 6148874.
Marc
Subscribe to:
Posts (Atom)