Tuesday, April 28, 2009

Find a string in all file on Linux

find . -exec grep -il 'string_to_find' {} \;

Tuesday, December 30, 2008

How to Access BPEL Variables in a Java Embed Activity

In your embedded Java you can use:

javaVar = getVariableData("BPEL_Variable_Name");

and

setVariableData("BPEL_Variable_Name", javaVar);

Obviously, the types need to match up!

Also useful for debugging/logging purposes is:

addAuditTrailEntry("My Message Goes Here:",optionalJavaVarValueToLog);

Wednesday, October 29, 2008

How to Create A Multiple Entry Point BPEL Process Using Pick


In RIA development we want frequently want to consume web services. From a organizational point of view we typically want related methods to be provided by the same provider. If the web service is being provided via a BPEL process, how can we do that?

The answer is to use a BPEL process with a Pick activity.

Steps:

1) Create a normal synchronous BPEL process. Let the wizard create it's default input and output variables, as these won't be used.

2) Drop your custom input and output XSD files into the /bpel directory

3) Delete the the client partner link. When you do you'll be asked if you want to delete the Partner link -- answer Yes. You'll also be asked if you want to delete the WSDL file -- answer No to this.

4) Drop a Pick activity between the existing Receive and Reply activities. Now delete the Receive and Reply activities.

5) Edit the project WSDL file:
a) In the types section, delete the imports for the default XSD file, and add imports for your custom XSD files
b) Delete the existing messages and create a message for each request and response message you will be defining
c) Delete the existing portType definition. Add a new one, and under the portType add a new operation for each method you are implementing in this BPEL process via the Pick
d) Change the existing partnerLinkType to use your new portType

6) You will need to create an onMessage branch in the Pick for each operation being implemented:
a) Double click the message icon and select the partner link to associate with this message. On the first message you will need to create a new partner link.
b) Create the new input message variable, selecting the desired message type.
c) Select the appropriate operation type. This will bind the partner link message to this message branch.

7) You will need to add a sequence (or a scope/sequence combination) to each message branch and provide the rest of the activities within it.

8) If you are returning multiple return types (most likely), each branch will need a Reply activity at then end of it to return the output to the client.

Monday, October 27, 2008

Enable/Unlock OID User Account Using Java API

How to programmatically enable and/or unlock a user's OID account using the Java API? Let's take a step by step look:

First get a reference to the directory context:

ctx = oracle.ldap.util.jndi.ConnectionUtil.getDefaultDirCtx(ldapHost, ldapPort, ldapUserCN, ldapCred );

ldapUserCN will most likely be something like "cn=orcladmin" and ldapCred will be the password for that CN.

Next, we build an attribute set that we are going to update. This will do the account enable:

attrSet = new javax.naming.directory.BasicAttributes();
attrSet.put("orclIsEnabled", "ENABLED");
ctx.modifyAttributes(userDN, javax.naming.directory.DirContext.REPLACE_ATTRIBUTE, attrSet);

userDN here will be the full DN of the user we are modifying. We can also force a new password by putting the attribute "userpassword" in the attribute set and giving it the new password as its value.

Finally, we will do the unlock:

attrSet = new javax.naming.directory.BasicAttributes();
attrSet.put("orclpwdaccountunlock","1");
ctx.modifyAttributes(userDN, javax.naming.directory.DirContext.ADD_ATTRIBUTE, attrSet);

You should note that if you are modifying the user password programmatically, the password must adhere to all of the normal password rules set up for your OID instance.

The code can throw javax.naming.directory.InvalidAttributeValueException , which can be caused by a password not adhering to the OID policies.

Friday, September 12, 2008

Worklist Application Issue When Switching to OID Security Provider

In the Oracle 10.1.3.3.x BPEL server there is an issue with tasks disappearing from everyone's task list after the server has been switched to use OID as the security provider.

The issue is that along with user ID's, the worklist application maintains the user's identity context in several of the workflow data base tables, including: WFTASK, WFTASKHISTORY, WFUSERPREFERENCE, WFUSERTASKVIEW, WFUSERTASKVIEWGRANT, WFUSERVACATION, and WFNOTIFICATIONSTATUS. The column in each of these tables is IDENTITYCONTEXT

Oracle is working an active bug for the issue where the migration scripts do not change the identity context columns, but until then you may want to think about manually updating the column values. This is not recommended by Oracle support, but was the only way I found to get existing tasks to show in user's task lists and task history again....

Wednesday, September 10, 2008

Switch OC4J from OID back to File Based Security

The switch from file based security to OID (or LDAP) based security is well documented by Oracle, but what if you ever need to switch back?

The obvious thing to do it do go into Enterprise Manager and change all of the providers back to "File Based Security". This will get you close, but not quite there.

The next thing you need to do is to roll back the changes to the jazn.xml files that were made for each container during the original switch to OID. Hopefully, you saved a copy of these! Don't forget to roll back jazn.xml for each container.

The last thing, if you are using BPEL, is to check the is_config.xml file for the BPEL container. This file is in $SOA_HOME/bpel/system/services/config. If you didn't save a copy of this file, there should be a clean one present in is_config.xml.BPM.

Finally, restart the application serrver and you should be back to file based security.

Wednesday, July 30, 2008

Find the OPMN Port for Java BPEL API Calls

Frequently, you'll need the OPMN request port for doing Java BPEL API calls.

You can find this value by looking at the opmn.xml file on the mid tier application server. It is in the $ORACLE_SOA_HOME/opmn/conf directory. Around the 5th line down in the "port" tag, you'll need to use the port number specified in the "request" attribute.