Java Transaction Service (JTS) specifies the implementation of a transaction manager that supports the Java Transaction API (JTA) specification (see JSR 907) at the high level and implements the Java mapping of the OMG Object Transaction Service (OTS) specification at the low level. JTS uses the standard CORBA ORB/TS interfaces and Internet Inter-ORB Protocol (IIOP) for transaction context propagation between JTS transaction managers.
A JTS transaction manager provides transaction services to the parties involved in distributed transactions: the application server, the resource manager, the standalone transactional application, and the Communication Resource Manager (CRM).
http://java.sun.com/javaee/technologies/jts/index.jsp
Tuesday, November 25, 2008
Thursday, November 13, 2008
The command to make environment variables effective immediately in Linux
In linux platform, sometimes you have to modify the .bash_profile under the root of login user to make changes on the environment variables. After it is changed, there are two common ways to make it affected: 1. relogin; 2. restart the system. Both of these two methods are not good.
Here a new command you can execute after changing it: source .bash_profile
After executing it, the modification of environment varaibles become effective immediately.
Such as after installing Oracle Database on Linux, you have to add the Oracle environment variables: ORACLE_HOME, ORACLE_SID to make it effective in Linux immediately.
Here a new command you can execute after changing it: source .bash_profile
After executing it, the modification of environment varaibles become effective immediately.
Such as after installing Oracle Database on Linux, you have to add the Oracle environment variables: ORACLE_HOME, ORACLE_SID to make it effective in Linux immediately.
Tuesday, September 2, 2008
Multiple realms support in BPEL 10.1.3
Today we have such scenarios that the application has to be approved by several persons from different departs or branches. So i use multiple realms in identity service to simulate the branches.
The multi-realm support does work in 10.1.3.
Multi-realm functionality works as follows: A task can only refer to users in one realm during its life cycle. If you choose a sequential pattern then all users need to be in the same realm. If you want a task to be routed between users in different realms then you need to model them different usages of the task (different human task activities) in BPEL where each one has a different realm associated with it and use the continue task (include task history from another task) feature while modeling so the same information gets routed to assignees across realms.
To associate a specific realm to a task you need to do the following to overcome a Jdev limitation. Go to the source editor of BPEL and locate the assign statement before the initiation of the task. Specify an extra copy statement in the assign to set the realm for that usage of the task in the BPEL process (note: realm and identityContext are often used interchangeably). For assigning tasks to users in branch office 1 (realm configured as 'branchOffice1') you should do the following:
<copy>
<from expression="string('branchOffice1')"/>
<to variable="initiateTaskInput" part="payload"
query="/taskservice:initiateTask/task:task/task:identityContext"/>
</copy>
Here are the steps' details to support multiple realms:
1. create different realms to be used through application server console: under orabpel application.
2. create users and groups for each realm defined in the above through application server console.
3. add more configures of realms new defined into identity service: <soa_home>/bpel/system/services/config/is_config.xml
For example:
<?xml version = '1.0' encoding = 'UTF-8'?>
<ISConfiguration xmlns="http://www.oracle.com/pcbpel/identityservice/isconfig">
<configurations>
<configuration realmName="jazn.com" default="true">
<provider providerType="JAZN" name="XML" service="Identity">
<property name="usersPropertiesFile" value="users-properties.xml"/>
</provider>
</configuration>
<configuration realmName="test.com">
<provider providerType="JAZN" name="XML" service="Identity">
<property name="usersPropertiesFile" value="test-users-properties.xml"/>
</provider>
</configuration>
</configurations>
</ISConfiguration>
Note: if more than one realms are provided, you have to set one as default using this attribute:default="true".
4. add the users and groups' information into a new user property file. Such as: test-users-properties.xml in above case under the same folder of is_config.xml.
5. Open up JDev to develop human task in BPEL view. You can find all the configured realms are listed in a select-input box. Then you assign the tasks to the users or groups picked up from different realms.
6. This step is quite important as it has to be done manually. After that, you will find there is no any information about the realm, which the choosen user or group belong to. So we have to add the realm info into this human task manually, assign the realm used to task identity context before invoking the task services:
<copy>
<from expression="string('branchOffice1')"/>
<to variable="initiateTaskInput" part="payload"
query="/taskservice:initiateTask/task:task/task:identityContext"/>
</copy>
7. Run it. It should work now.
The multi-realm support does work in 10.1.3.
Multi-realm functionality works as follows: A task can only refer to users in one realm during its life cycle. If you choose a sequential pattern then all users need to be in the same realm. If you want a task to be routed between users in different realms then you need to model them different usages of the task (different human task activities) in BPEL where each one has a different realm associated with it and use the continue task (include task history from another task) feature while modeling so the same information gets routed to assignees across realms.
To associate a specific realm to a task you need to do the following to overcome a Jdev limitation. Go to the source editor of BPEL and locate the assign statement before the initiation of the task. Specify an extra copy statement in the assign to set the realm for that usage of the task in the BPEL process (note: realm and identityContext are often used interchangeably). For assigning tasks to users in branch office 1 (realm configured as 'branchOffice1') you should do the following:
<copy>
<from expression="string('branchOffice1')"/>
<to variable="initiateTaskInput" part="payload"
query="/taskservice:initiateTask/task:task/task:identityContext"/>
</copy>
Here are the steps' details to support multiple realms:
1. create different realms to be used through application server console: under orabpel application.
2. create users and groups for each realm defined in the above through application server console.
3. add more configures of realms new defined into identity service: <soa_home>/bpel/system/services/config/is_config.xml
For example:
<?xml version = '1.0' encoding = 'UTF-8'?>
<ISConfiguration xmlns="http://www.oracle.com/pcbpel/identityservice/isconfig">
<configurations>
<configuration realmName="jazn.com" default="true">
<provider providerType="JAZN" name="XML" service="Identity">
<property name="usersPropertiesFile" value="users-properties.xml"/>
</provider>
</configuration>
<configuration realmName="test.com">
<provider providerType="JAZN" name="XML" service="Identity">
<property name="usersPropertiesFile" value="test-users-properties.xml"/>
</provider>
</configuration>
</configurations>
</ISConfiguration>
Note: if more than one realms are provided, you have to set one as default using this attribute:default="true".
4. add the users and groups' information into a new user property file. Such as: test-users-properties.xml in above case under the same folder of is_config.xml.
5. Open up JDev to develop human task in BPEL view. You can find all the configured realms are listed in a select-input box. Then you assign the tasks to the users or groups picked up from different realms.
6. This step is quite important as it has to be done manually. After that, you will find there is no any information about the realm, which the choosen user or group belong to. So we have to add the realm info into this human task manually, assign the realm used to task identity context before invoking the task services:
<copy>
<from expression="string('branchOffice1')"/>
<to variable="initiateTaskInput" part="payload"
query="/taskservice:initiateTask/task:task/task:identityContext"/>
</copy>
7. Run it. It should work now.
Wednesday, July 23, 2008
Qualified XSD Schema in BPEL/ESB
Maybe you have met this kind of problems to say that the input data is received correct, but its values can't be accessed through XPATH before as reporting the Null error.
Once this problem occurs, please check one setting: elementFormDefault="qualified", in XSD schema containing the elements or attributes mapping to the XML file.
This important attribute is on schema tag in XSD, which means all the elments inside are qualified and then can be used correctly.
Such as:
<schema attributeformdefault="unqualified" elementFormDefault="qualified" targetNamespace="http://xmlns.oracle.com/AsynHello" xmlns="http://www.w3.org/2001/XMLSchema">
...
</schema>
Once this problem occurs, please check one setting: elementFormDefault="qualified", in XSD schema containing the elements or attributes mapping to the XML file.
This important attribute is on schema tag in XSD, which means all the elments inside are qualified and then can be used correctly.
Such as:
<schema attributeformdefault="unqualified" elementFormDefault="qualified" targetNamespace="http://xmlns.oracle.com/AsynHello" xmlns="http://www.w3.org/2001/XMLSchema">
...
</schema>
Tuesday, July 22, 2008
Installing a loopback adapter for Oracle SOA Suite
A loopback adapter is required in any of these scenarios:
- you are installing on a DHCP computer.
- you are installing on a non-networked computer and plan to connect the computer to a network after installation.
- you are installing on a computer with multiple aliases.
- you are installing on a networked computer (with static IP or DHCP), but you want to be able to run Oracle Application Server when you take the computer off the network..
Using hostname during installing Oracle SOA Suite
To ensure that the installer uses the local hostname, you have two options:
- Option 1: Start up the installer with the OUI_HOSTNAME parameter. This parameter specifies the hostname that you want to use.
E:\> setup.exe OUI_HOSTNAME=myhostname.mydomain.com
- Option 2: Before running the installer, add a line to the C:\winnt\system32\drivers\etc\hosts file with the following format:
IP_address hostname.domainname hostname
This line should come after the localhost line in the file.
Replace IP_address with the loopback adapter's IP address. This should be a non-routable IP address.
Replace hostname and domainname with the appropriate values.
Example:10.10.10.10 mycomputer.mydomain.com mycomputer
If you have already installed Oracle Application Server, you can change the hostname after installation using the change IP/hostname procedures documented in the Oracle Application Server Administrator's Guide.
Monday, July 21, 2008
Domain Value Mapping in BPEL process
As we know, DVM is an important function during data transfer. It can be used not only in ESB project, but also in BPEL Process, even though it has to be defined in ESB Control.
It is invoked by this xpath function 'orcl:lookup-dvm' provided by Oracle.
Here is the example:
orcl:lookup-dvm('SampleDVM','SourceColumn',/ns1:DomainValueMappingProcessProcessRequest/ns1:input,'TargetColumn',/ns1:DomainValueMappingProcessProcessRequest/ns1:input)
There are totally five input params:
1st: DVM name
2nd: Source column name defined in the DVM.
3rd: XPath of source data to be transferred, which will not be wrapped as string. In another word, there is no double quote marks at the begining and end of it. If it uses double quote marks, it means this param is a constant.
4th: Target column name
5th: Default value. If it is from a BPEL variable, please don't quote it with double quote marks.
It is simple, but you have to pay attention to the 3rd and 5th parameters if the value of them are dynamic.
It is invoked by this xpath function 'orcl:lookup-dvm' provided by Oracle.
Here is the example:
orcl:lookup-dvm('SampleDVM','SourceColumn',/ns1:DomainValueMappingProcessProcessRequest/ns1:input,'TargetColumn',/ns1:DomainValueMappingProcessProcessRequest/ns1:input)
There are totally five input params:
1st: DVM name
2nd: Source column name defined in the DVM.
3rd: XPath of source data to be transferred, which will not be wrapped as string. In another word, there is no double quote marks at the begining and end of it. If it uses double quote marks, it means this param is a constant.
4th: Target column name
5th: Default value. If it is from a BPEL variable, please don't quote it with double quote marks.
It is simple, but you have to pay attention to the 3rd and 5th parameters if the value of them are dynamic.
About obtaining the modification time of files using FTP Adapter
Maybe some of you met this kind of problems which said the modification time of files on FTP server were not set properly or related information of it were reported during runtime after configuring the FTP Adapter. Even though the time format was correct through verified with the file system listing command: quote mdtm filename. But it would be the problem of time zone either.
To solve this problem, the easiest way is to erase these below properties: FileModificationTime and ModificationTimeFormat from the FTP Adapter wsdl file.
Then test it and it will work correctly.
To solve this problem, the easiest way is to erase these below properties: FileModificationTime and ModificationTimeFormat from the FTP Adapter wsdl file.
Then test it and it will work correctly.
Sunday, July 20, 2008
I am coming
Oh... it is unbelievable that i have a blogger of my own. I will post what i think and what i have seen on it and share them with all of you. Hoep you guys like it.
Subscribe to:
Posts (Atom)