Access profiles

It is very common, especially when building Web applications, to require a different level of detail on various web pages for the same object. For example, on a product list page, only minimal information about each product is needed, while on a product detail page, more information is required. To accommodate the varying needs for different levels of knowledge about an object, clients can use access profiles to convey the intent of their requests. Access profiles are keys that allow you to change the amount and type of response data being returned by a particular XPath expression. The access profile is used to choose the SQL statement from the Query template file that retrieves data. We must always specify the access profile. For example, the following query specifies the IBM_Admin_Details access profile:

Note: IBM_Admin_ prefixes all services intended to be used by admin/CMC based services calls. Access profiles which do not follow the new naming conventions continue to function correctly, as compatibility is maintained with earlier versions. IBM recommends, however, that they are followed for existing access profiles, and when making changes to future access profiles.

{_wcf.ap=IBM_Admin_Details}/CatalogGroup[Name='MyCatalogGroupName']

There are two ways to use the access profile to scope your response data:

1. Define a XPATH_TO_SQL_STATEMENT block in the query template file. The template name is the XPath_key+Access_profile, where XPath_key is the key generated from an XPath query and Access_Profile is the name of the access profile. The access profile together with the XPath key is used to locate the necessary query template in the template file.

2. Define the access profile in the PROFILE section of the query template file, and define one or more SQL templates under the ASSOCIATON_SQL_STATEMENT section. When the DSL is called with this access profile, the associated SQL is run. We can use this method to structure a query to retrieve a set of objects, then use the associated SQL, to retrieve information about those objects. For information about configuring access profiles, see Query template file.

Access profile extensions

We can extend an access profile, including WebSphere Commerce default access profiles. An example of the syntax in our custom query template file is:

BEGIN_SYMBOL_DEFINITIONS
	COLS:CATENTRY=CATENTRY:* 
	COLS:XWARRANTY=XWARRANTY:*
END_SYMBOL_DEFINITIONS

BEGIN_ASSOCIATION_SQL_STATEMENT
	name=MyAssociatedQuery
	base_table=CATENTRY
	sql=
	     SELECT CATENTRY.$COLS:CATENTRY$,
                XWARRANTY.$COLS:XWARRANTY$
	     FROM
	          CATENTRY 
                   LEFT OUTER JOIN XWARRANTY ON 
                     (CATENTRY.CATENTRY_ID = XWARRANTY.CATENTRY_ID)
             WHERE
                   CATENTRY.CATENTRY_ID IN ($ENTITY_PKS$) 
END_ASSOCIATION_SQL_STATEMENT

BEGIN_PROFILE
	name=MyProfile
	extends = IBM_Admin_Summary
	associated_sql_statement=MyAssociatedQuery
BEGIN_ENTITY

In the example, the access profile MyProfile is extending IBM_Admin_Summary, a default WebSphere Commerce access profile. A new associated SQL statement block, MyAssociatedQuery, is also defined. This SQL statement must be in the same query template file as the new access profile.

Note: When selecting a subset of columns from the extension table (or any table associated with the base table), we must always select the primary key of the custom table and the foreign key to the base table. If not, WebSphere Application Server is incapable of building the relationship between the base table object and the extension table object. Restriction:

• Only one level of inheritance is supported in access profile extension.

• If you do not extend an IBM profile, we cannot reuse an existing associated SQL.

• Implementing a new custom Graph composer is needed if we are extending a default WebSphere Commerce access profile with more than one associated SQL and one of the following conditions is true:

  • The access profile we are extending is using a non-default Graph composer class.

  • The result set of all associated SQL statements (referenced by both the default and custom access profiles), retrieve identical records from tables other than the base table.

    The base table name should not be specified in the new access profile. It is inherited from the original profile. The associated SQL templates referenced by the extension profile should specify the same base table name as the one used in the default profile. In the preceding example, the base table for the MyNewAssociatedSQLName SQL statement is the same as the base table in the parent access profile, CEDescriptionProfileWithAdditionalObject.