Customizing WebSphere Commerce to meet business logic starts with defining what assets your are dealing with. Categorizing your business assets can also mean finding commonalities with those store relationship types already defined in WebSphere Commerce. The following are the store relationship types already defined in an extended site in an available-to-market deployment:
If you feel your business logic is dealing with assets that do not belong to the available-to-market store relationship types, then you can create a custom store relationship type.
Listing 12. Example store relationship type entry
insert into streltyp (name,streltyp_id) values ('com.dw.commerce.storepath.affiliate',5);
This new store relationship type may be mutually exlcusive to other store relationship types, or they can be considered a sub-set of assets to another store relationship type. You can create new store relationship types to provide more granular control of existing WebSphere Commerce assets. That way, you do not have to write code specific to a single store, but have a common code base that any store can use based on their participation in the store relationship entries. If you pull assets for one store relationship type in the same call as it belongs to another set of assets, then you may have to filter the returning results by inspecting the returning store identifier value and ignoring the value if that store identifier belongs to another store relationship. For example, if you are determining assets for affiliates on the store level only, but the catalog store relationship type is defined on the asset store level, then you may have to inspect the returning related store identifier value to ensure no conflict.
There is a simple utility class you can use to pull all the related
store identifiers for a given store relationship type and store
An array of store identifier values is returned. The index of the
array is congruent with the sequence value from the STOREREL table.
The way you use that data is up to you, either use all values to find
corresponding assets by the foreign key store identifier, or use a
specific index from the array based on some conditional rule.
When dealing with entity beans, you can append a sub-query based on
the store relationships directly into the EJB
UserFinderDescriptor finder type
FinderHelper method. This is done by including a
BeanFinderObject class that the entity bean
picks up to merge the SQL statement.