Tuesday, 30 September 2014

Access Bean in Websphere Commerce

WebSphere Commerce commands can't interact directly with entity beans but it does it through access beans .Access beans acts as a simpler interface to clients, caching of the home object, and reduced call traffic to the enterprise bean.Access beans is similar to like Java beans, and it hides all enterprise bean-specific programming interfaces from the client, like the JNDI, home and remote interfaces. 

Advantages of using AccessBeans
During run time the access bean caches the enterprise bean home object to avoid look ups to the home object as it is  expensive.Access bean implements a copyHelper object which reduces the number of calls to the enterprise bean when commands get and set enterprise bean attributes. Only a single call is required for multiple attributes.In the access bean, the get and set methods are not automatically cached. Only the methods that are part of the copy helper object are cached. 

Types of Access beans are:
1. Copy Helper methods.

2. Finder methods.

3. EJB methods.
The access bean implements a copyHelper object that reduces the number of calls to the enterprise bean when commands get and set enterprise bean attributes. Only a single call to the enterprise bean is required when reading or writing multiple bean attributes.The copy helper object is stored inside the access bean.A getter and setter method is delegated to the local copy helper object instead of the remote enterprise bean object.To commit the changes in the copy helper to the remote enterprise bean or to refresh the local copy helper from the remote enterprise bean, your client program must call commitCopyHelper() and refreshCopyHelper() respectively.
There are 2 types of Copy Helper methods:

1. refreshCopyHelper()

2. commitCopyHelper()

refreshCopyHelper(): refresh copy helper is treated as "find for update” and it locks that particular row unless or until you are done with entire transaction. So you read something with refreshcopyHelper and you keep doing  no of things and when you are finally done then only these locks are released.
commitCopyHelper(): commitCopyHelper() takes the current state of the access bean and updates the database with it.

Finding data using an access bean

Finding data by primary key

//create a new access bean
UserProfileAccessBean userProfileAccessBean = new UserProfileAccessBean();
// set the primary key
//call getter to get the DisplayName. 
String myDisplayName = userProfileAccessBean getDisplayName();

When to use refreshCopyHelper()

Use the refreshCopyHelper method to retrieve information from the database and populate the access bean. You do not need to use the refreshCopyHelper() if you are using a getter method to retrieve specific data from the access bean. You only need to use it to explicitly tell the access bean to populate itself.

//Create a new access bean
UserProfileAccessBean userProfileAccBean = new UserProfileAccessBean();
//Set the primary key
//Call refreshCopyHelper to populate it with data

Finding data using a finder method

These methods will return you an Enumeration of access beans that match the find criteria. If records are found, there will be one or more fully populated access beans in the Enumeration. If the result of the finder is empty, the finder method will throw javax.ejb.ObjectNotFoundException.
AddressAccessBean addressAccessBean = new AddressAccessBean().findByNickname("nickname", new Long("10001"));
Where nickname is the search term used for the nick name.
Inserting data using access beans

You can access beans to create new data as part of your business logic.To create new data, use any access bean constructor with one or more arguments. You can then set any additional data on the bean using the provided setters, and call the commitCopyHelper() method.
//Create a new fulfillment center record.
FulfillmentCenterAccessBean fulfillmentCenterAccessBean = new FulfillmentCenterAccessBean(ownerId, fflname);
//Set additional data on the access bean.
fulfillmentCenterAccessBean .setInventoryOperationFlags(flags);
//Commit the inventory operation flags update
fulfillmentCenterAccessBean .commitCopyHelper();

No need to call commitCopyHelper() if you create the record using only the constructor, and do not call additional setters.
Deleting data using an access bean

You can delete data from the WebSphere Commerce database in your business logic using the remove() method on the access bean's EJB remote interface.The EJB remote interface can be obtained by using the getEJBRef() method on the access bean.

// Delete record using an AccessBean
catch( ObjectNotFoundException e) {
// Tried to delete a record that does not exist

EJB files to be committed  in SVN(Repository) after creating \ updating EJB (Using IBM DB2 DataBase v9.7)

Below are the list of files to be committed  to repository after create\update an EJB



Thursday, 25 September 2014

Merchant Key in Websphere Commerce

In Websphere Commerce,Passwords are never decrypted during the authentication process, as is the common security practice. All user passwords are one-way hashed and encrypted using a 128-bit key, known as the merchant key. The merchant key is specified during installation and configuration of the WebSphere Commerce system.

Each Full WebSphere Commerce Test Environment will have a merchant key associated with it. This is the merchant key that was entered during Database instance creation.
Retrieving Merchant Key from WebSphere Commerce

While installing the websphere commerce server you normally provide the merchant key and that key will be used for enrypting and decrypting different values in the system. When we want to directly encrypt the value using the wcs utilities we have to provide the merchant key and if we forget the merchant key we can directly get it from the server using the following methods

com.ibm.commerce.server.ConfigProperties.singleton ().getMerchantKey()

The above methods are there in WCS6. WCS7 on wards you have to use the following
<%@ page import="com.ibm.commerce.util.nc_crypt" %>

<p>Encrypted Merchant Key: <%=com.ibm.commerce.server.WcsApp.configProperties.getValue("Instance/MerchantKey")%></p>

<p>Decrypted (Plain Text) Merchant Key: <%=nc_crypt.decrypt(com.ibm.commerce.server.WcsApp.configProperties.getValue("Instance/MerchantKey"), null)%></p>

MigrateEncryptedInfo utility
MigrateEncryptedInfo is a utility for changing the merchant key and re-encrypt all encrypted data in the database. There are two ways to specify the values of the merchant key to this tool. The first way is to provide the old and new merchant keys through command line arguments. The second way is to retrieve the keys from calling out to the Key Locator Framework using the "-k" parameter.

migrateEncryptedinfo.sh database_type   instance_name  num_of_threads     commit_count  current_merchant_key new_merchant_key     -k keys_config_file_location

Is your database type, and is either db2 for DB2 databases or oracle for Oracle databases.

Is a mandatory parameter for the name of the instance which will be updated.

num_of_threads (fixpack5)
The number of threads that are spawned to re-encrypt the data. The recommendation is that this number should match the number of processors on the server running the utility.

The number of records that will be processed before the transaction is committed.  The commit_count should be set to the maximum number of transactions that your database transaction log will allow. A suggested value for this parameter is 5000.
If the merchant keys are not retrieved from the Key Locator Framework, these are the accepted parameters:

An optional parameter for the current merchant key, in clear text (ASCII) form. You should specify this parameter only if you are currently using a non-default merchant key, and you are now changing it to a new merchant key. In this case, you should also specify the new_key parameter. If you are currently using the default WebSphere Commerce Suite 5.1 merchant key, do not specify this parameter. The utility will detect that you are using the default key.

A required parameter that should be specified if you are currently using the default merchant key. If you are already using a non-default merchant key, then this parameter is optional. This parameter should be in clear text (ASCII) form. It must conform to the following rules:
Its length must be 16 hexadecimal characters. Characters can be one of 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, a, b, c, d, e, or f.
It must contain a minimum of one alphabetic character.
It must contain a minimum of one numeric character.
It must be in lowercase.
It cannot contain more than 4 consecutive characters.
For example, aaaa1aaaa1aaaa12 and abcdeaaaa3aaaa12 are allowed. However, aaaaabaaaa1aaaa1 is not allowed as it is greater than 16 characters in length and contains more than four consecutive characters.
If the merchant keys are retrieved from the Key Locator Framework, here is the accepted parameter:

-k keys_config_file_location
The current and new merchant keys are to be retrieved from the Key Locator Framework using the specified key configuration file. The absolute path of the file must be specified.


If your merchant key is currently stored in the instance.xml file and you want to change the value without moving the another location, run the utility as follows, assuming the encrypted data is stored in a DB2 database and "demo" is the instance name:

MigrateEncryptedInfo db2 demo 1234567890abcdef    abcdef1234567890

From fix pack5
MigrateEncryptedInfo db2 demo 4 5000 1234567890  abcdef abcdef1234567890

Note: The WebSphere Commerce version example is setting the num_of_threads value to 4 (for a 4-processor server) and the commit_count to 5000.

Then Run the command to update the server with the data

Start the WebSphere Commerce instance.
Run the following command:

WC_installdir/bin/config_ant.sh -DinstanceName= instance_name UpdateEAR
WC_installdir/bin/config_ant.bat -DinstanceName= instance_name UpdateEAR

Restart your WebSphere Commerce instance.

Key Locator Framework (KLF)

Allows for encryption keys to be stored in a configurable location by using a key provider class
Two implementations are provided by WebSphere Commerce

WCMerchantKeyImpl – stored in instance.xml (default as defined in WCKeys.xml)
WCExternalFileMerchantKeyImpl – stored in external file. Allows for split keys
Key Locator Framework – Changing the default

Add KeysConfigFile=”CustomKeys.xml” to <Instance> of instance.xml .CustomKeys.xml then defines the key(s) being used.It Can have multiple MerchantKeys defined, differentiated by “status” and/or “version

 <key name="MerchantKey"
 className ="com.ibm.commerce.security.keys.WCMerchantKeyImpl">

 <key name="MerchantKey"
 className ="com.ibm.commerce.security.keys.WCExternalFileMerchantKeyImpl">
 config name ="keyFile" value = "merchantKey.xml" />
 config name ="newKeyFile1" value = "keyFile1.xml" />
  config name ="newKeyFile2" value = "keyFile2.xml" />
<key> tag
status – can be “current”, “new” or “pending
Pending only used in few scenarios
version – required as of Feature Pack 3. Must increase each time data migrated

<config> tag
name=”keyFile” – stores the merchant key
name=”keyEncryptionFile” – stores the key encryption key (encrypts new plaintext merchant key)
name=”newKeyFileX”– stores one half of the new merchant key