ProductLookup Droplet : ATG

We used /atg/commerce/catalog/ProductLookup, a component that is an instance of atg.commerce.catalog.custom.CatalogItemLookupDroplet class, to fetch product attributes from the repository. This is the beginning of the code from product.jsp where we used the ProductLookup component: 


<dsp:droplet name="/atg/commerce/catalog/ProductLookup">
  <dsp:oparam name="output">
…
<table border=0 cellpadding=4>
<tr>
   <td>
      <span class=categoryhead>
      <dsp:valueof param="element.displayName">No name</dsp:valueof></span>
      <br>
      <b><dsp:valueof param="element.description"/></b></td>
   </td>
</tr>
<tr valign=top>
   <td>
      <dsp:include page="../common/FormError.jsp" flush="false"></dsp:include>
      <dsp:droplet name="IsEmpty">
         <dsp:param name="value" param="element.largeImage.url"/>
         <dsp:oparam name="false">
      <dsp:getvalueof id="imageURL" param="element.largeImage.url"
         idtype="java.lang.String">
         <dsp:img hspace="70" alt="Product image" src="<%=imageURL%>"/>
      </dsp:getvalueof>
      </dsp:oparam>
      </dsp:droplet>

      <dsp:getvalueof id="pval0" param="element"><dsp:include
         page="SKUProperties.jsp" flush="false"><dsp:param name="product"
         value="<%=pval0%>"/></dsp:include></dsp:getvalueof>
      <br>
      <span class=smallb>Product Description</span><br>
      <span class=small><dsp:valueof param="element.longDescription">
         No description</dsp:valueof>
      </span>
   </td>
</tr>
</table>
…
</dsp:oparam>
</dsp:droplet>




ProductLookup takes an id parameter as input; in this case, it is the repository ID of the product, from the product link the user clicked on the category page. It then binds the element parameter to the product with the id that was passed in. In this code example, we didn’t explicitly pass the id parameter to the ProductLookup component. The page-level id parameter was already defined at the top of the page as an input parameter and thus implicitly passed to ProductLookup.



The following code shows how we displayed the product’s longDescription property, or, a default value if the product does not have a longDescription value:

<dsp:valueof param="element.longDescription">No description</dsp:valueof>

The following code example shows how we displayed the product’s image if it is not null.



<dsp:droplet name="IsEmpty">
   <dsp:param name="value" param="element.largeImage.url"/>
   <dsp:oparam name="false">
      <dsp:getvalueof id="imageURL" param="element.largeImage.url"
         idtype="java.lang.String">
      <dsp:img hspace="70" alt="Product image" src="<%=imageURL%>"/>
      </dsp:getvalueof>
   </dsp:oparam>
</dsp:droplet>



                                                                                                                                                                    

Setting Up The Promotion via an URL : ATG

You can set a promotion to site visitors in a variety of ways, such as via a scenario or coupon. The preceding sections describe how to create promotions and use these delivery methods. This section provides information on another way to deliver a promotion to site visitors – via a URL on a JSP. You embed the ID of the promotion you want to offer in the URL. When a site visitor clicks that URL, the promotion is added to the visitor’s activePromotions Profile property.

To deliver a promotion via a URL, do the following:

Enable the /atg/commerce/promotion/PromotionServlet by setting its enabled property to true in its .properties file. By default, ATG Commerce inserts PromotionServlet in the request-handling pipeline, but you must enable it for use.

Include a URL on the desired JSP using an anchor tag like the following:

<dsp:a href="../../samplepage.jsp" encode="true">
<dsp:param value="promo1000001" name="PROMO"/>
Click here to get a 40% discount on shirts.
</dsp:a>


where ../../samplepage.jsp is the page to which you want to link, and the value of the PROMO request parameter is the ID of the promotion in the /atg/commerce/pricing/Promotions repository.


Note that encode=true is required in the anchor tag. This causes the PROMO parameter subtag to be encoded into the URL as a URL parameter and not a query parameter. In turn, PromotionServlet calls getURLParameter() on the request to retrieve the PROMO parameter value.

Also Note that the item descriptor of the promotion must be one of the item descriptors in PromotionServlet.promotionItemDescriptorNames.

When a request is passed into PromotionServlet, if the servlet is disabled, it simply passes the request to the next servlet in the pipeline. If it is enabled, it looks for a PROMO parameter in the URL parameters of the request and retrieves the associated promotion ID. Next, the servlet looks for a promotion in the Promotions repository whose ID is the given ID and whose item descriptor is included in PromotionServlet.promotionItemDescriptorNames. If the promotion exists, then PromotionServlet checks that either the profile is persistent or the promotion’s Give To Anonymous Customers (giveToAnonymousProfiles) property is set to true. If either condition is true, the promotion is added to the user’s activePromotions Profile property.

Integration Approaches : ATG

Integration Approaches

The Integration Repository is designed to help integrate ATG applications with remote systems. It assumes that your business maintains data on a remote system and you want to expose and possibly modify this data within your ATG application in the form of ATG repository items. There are several ways you can set up such an integration, depending on the demands of your ATG application and the characteristics of the remote system and the data maintained there. Here are four possible approaches for getting remote data. Which approach to choose depends on balancing your need for consistent data and best performance.

Types of Integration Approaches

1.Remote Only
2.Remote then Local
3.Local then Remote
4.Local Only

Remote Only

In this case, the data is maintained only on the remote system. Each time that the ATG application needs to access the data, a command is issued to the remote system. The local repository is configured to use transient repository items.

Advantages:

1.You are always sure that the data returned to ATG is up to date.

Disadvantages:

1.If the remote system is unavailable, then no form of the data is available to the ATG application.

2.Frequent queries to the remote system can affect the performance of the remote system, which may also be serving functions other than the ATG application.

3.The need to query the remote system will tend to slow the performance of the ATG application.

Configuring the Remote-Only Model

The Remote Only model is sketched in the Integration Approaches section. In this use case model, the data is maintained only on the remote system. Each time that the ATG application needs to access the data, a command is issued to the remote system.

To configure this integration model, configure your Integration Repository with transient properties. None of the repository item properties will be stored in the local repository database, so there are no table tags defined in the local repository definition file. In addition, the local-value-timeout attribute in the item descriptors of the Integration Repository is set to a small value. For example, the local repository definition might look like this:

localRepositoryDefinition.xml

<gsa-template>
 <item-descriptor name="contact" display-property="lastName">
 <property name="id" data-type="string"/>
 <property name="firstName" data-type="string" display-name="First Name"/>
 <property name="lastName" data-type="string" display-name="Last Name"/>
 <property name="email" data-type="string" display-name="Email Address"/>
 </item-descriptor>
</gsa-template>

You can define a mapping file that specifies the names of these properties on the remote system:

mapping.xml

<item-descriptor
 repository-path="/atg/integrations/remotex/RemoteXIntegrationRepository"
 name="contact">
 <property name="id" targetName="Id" include="true"/>
 <property name="firstName" targetName="First Name" include="true"/>
 <property name="lastName" targetName="Last Name" include="true"/>
 <property name="email" targetName="Email Address" include="true"/>
</item-descriptor>
The Integration Repository definition file would then look like this:

integrationRepository.xml

<integration-repository-template>
 <item-descriptor name="contact"
 external-id-property="id" use-external-id="true"
 mapping-file="/atg/integrations/remotex/mapping.xml"
 local-value-timeout="1000">
 <query command="/atg/integrations/remotex/GetContacts"
 view-class="atg.integrations.remotex.RemoteXQueryView"/>
 <get-item command="/atg/integrations/remotex/GetContacts"
 use-local-on-failure="false"/>
 <update-item command="/atg/integrations/remotex/UpdateContacts"/>
 </item-descriptor>
</integration-repository-template>

This configuration means that queries and getItem operations use the GetContacts command. Users cannot remove or create contacts in the remote system, since no Command has been defined for these operations, but can update existing ones. If the remote system is unavailable in a getItem operation, then no data is available, since the use-local-on-failure attribute is set to false.

Note that you could change this to provide ATG with read-only access to the remote system by omitting the updateItem Command, leaving only the GetContactsCommand to query and get items.

Remote then Local

In this case, the primary source for the data is the remote system. Each time that the ATG application needs to access the data, a command is issued to the remote system. If the command fails to return, then the command is issued to the local repository.

Advantages:

You are sure that the data returned to ATG is up to date, except in cases where the remote system is unavailable. In addition, the existence of the local repository can provide a backup form of the data, in case the remote system is inaccessible.

Disadvantages:

1.Frequent queries to the remote system can affect the performance of the remote system, which may also be serving functions other than the ATG application.

2.The need to query the remote system will tend to slow the performance of the ATG application.

Configuring the Remote-then-Local Model

The Remote then Local model is sketched in the Integration Approaches section. In this case, the primary source for the data is the remote system. A local copy of the data is maintained in the local repository. Each time that the ATG application needs to access the data, a command is issued to the remote system. If the command fails to return, then the command is issued to the local repository.

To configure this integration model, use persistent properties that are stored through the local repository in a database on the local system. These persistent properties are defined within table tags in the local repository item descriptors. For example:

localRepositoryDefinition.xml

<gsa-template>
 <item-descriptor name="contact" display-property="lastName">
 <table name="contact" ... >
 <property name="id" data-type="string"/>
 <property name="firstName" data-type="string" display-name="First Name"/>
 <property name="lastName" data-type="string" display-name="Last Name"/>
 <property name="email" data-type="string" display-name="Email Address"/>
 </table>
 </item-descriptor>
</gsa-template>

integrationRepository.xml

The Integration Repository definition file uses the local-value-timeout attribute with a small value, so that subsequent attempts to access an item will continue to try the remote system before resorting to the local repository. In addition, the use-local-on-failure attribute for the getItem command is set to true.

<integration-repository-template>
 <item-descriptor name="contact"
 external-id-property="id" use-external-id="true"
 local-value-timeout="1000">
 <query command="/atg/integrations/remotex/GetContacts"
 view-class="atg.integrations.remotex.RemoteXQueryView"/>
 <get-item command="/atg/integrations/remotex/GetContacts"
 use-local-on-failure="true"/>
 <update-item command="/atg/integrations/remotex/UpdateContacts"/>
 </item-descriptor>
</integration-repository-template>

Local then Remote

In this case, a version of the data is maintained in a local repository. Only if the data is not available locally, or if the local copy has been marked invalid or has expired, does the Integration Repository query the remote system for the data.

You might use this integration model if you need to make sure the system is as fast as possible, and you don’t have to worry so much about data consistency because the data does not change that often. When the remote system is down, you can block changes to the data (updates, creating and removing items), but you make the data available from the local system, so that your users can continue to work.

Advantages:

1.ATG’s performance is as fast as possible.

2.There are fewer queries to the remote system, so less burden is placed on the remote system.

3.You can configure the lifetime of items in the local repository, so you can be assured that the data is not out of date by more than a specified amount of time.

Disadvantages:

You have less assurance that the data returned from the local repository is consistent with the data in the remote system.

Configuring the Local-then-Remote Model

The Local then Remote model is sketched in the Integration Approaches section. In this case, a version of the data is maintained in a local repository. Only if the data is not available locally, or if the local copy has expired or otherwise been marked invalid, do we query the remote system for the data.

To configure this integration model, use persistent properties that are stored through the local repository in a database on the local system. The local repository is defined pretty much the same way as in the Configuring the Remote-then-Local Model.

The Integration Repository definition is a bit different. It uses the local-value-timeout attribute with a large value, so that items will remain valid in the local repository for a reasonable length of time.

integrationRepository.xml

<integration-repository-template>
 <item-descriptor name="contact"
 external-id-property="id" use-external-id="true"
 local-value-timeout="3600000">
 <query command="/atg/integrations/remotex/GetContacts"
 view-class="atg.integrations.remotex.RemoteXQueryView"/>
 <get-item command="/atg/integrations/remotex/GetContacts"
 use-local-on-failure="true"/>
 <update-item command="/atg/integrations/remotex/UpdateContacts"
 timeout-response="UNKNOWN"/>
 <add-item command="/atg/integrations/remotex/AddContacts"
 timeout-response="INVALID"/>
 <remove-item command="/atg/integrations/remotex/RemoveContacts"/>
 </item-descriptor>
</integration-repository-template>

Local Only

This approach doesn’t need to use the ATG Integration Framework. In this case, we periodically dump data from the remote system into the relational database used by the ATG application. The data is accessed by the SQL repository. Since this approach doesn’t need to issue commands against the remote system in real time, there doesn’t need to be an Integration Repository.

Advantages:

1.ATG’s performance is as fast as possible.

2.The only interaction with the remote system is a periodic batch data transfer, which probably can be scheduled to place a minimal burden on the remote system.

Disadvantages:

1.The local repository is not updated in real time, so any changes in the remote system are reflected in the local repository and therefore in your Web application only after the scheduled data transfer.

Configuring the Remote-then-Local Model

The Remote then Local model is sketched in the Integration Approaches section. In this case, the primary source for the data is the remote system. A local copy of the data is maintained in the local repository. Each time that the ATG application needs to access the data, a command is issued to the remote system. If the command fails to return, then the command is issued to the local repository.

To configure this integration model, use persistent properties that are stored through the local repository in a database on the local system. These persistent properties are defined within table tags in the local repository item descriptors. For example:

localRepositoryDefinition.xml

<gsa-template>
 <item-descriptor name="contact" display-property="lastName">
 <table name="contact" ... >
 <property name="id" data-type="string"/>
 <property name="firstName" data-type="string" display-name="First Name"/>
 <property name="lastName" data-type="string" display-name="Last Name"/>
 <property name="email" data-type="string" display-name="Email Address"/>
 </table>
 </item-descriptor>
</gsa-template>

integrationRepository.xml

The Integration Repository definition file uses the local-value-timeout attribute with a small value, so that subsequent attempts to access an item will continue to try the remote system before resorting to the local repository. In addition, the use-local-on-failure attribute for the getItem command is set to true.

<integration-repository-template>
 <item-descriptor name="contact"
 external-id-property="id" use-external-id="true"
 local-value-timeout="1000">
 <query command="/atg/integrations/remotex/GetContacts"
 view-class="atg.integrations.remotex.RemoteXQueryView"/>
 <get-item command="/atg/integrations/remotex/GetContacts"
 use-local-on-failure="true"/>
 <update-item command="/atg/integrations/remotex/UpdateContacts"/>
 </item-descriptor>
</integration-repository-template>