Tuesday, April 30, 2013

Creating Custom Actions in Scenario : ATG


Implementing the Action Interface


The <action-class> tag above contains the class name of the atg.process.action.Action implementation that is invoked when your custom action occurs in a scenario. The Action interface refers to several other classes and interfaces. At a minimum, familiarize yourself with the following interfaces/classes before implementing your action:

atg.process.expression.Expression

atg.process.action.Action

atg.process.action.ActionImpl

atg.process.ProcessExecutionContext

The Expression interface represents an expression as described above (for example, “Person’s age,” or the value “249”). An Expression can be evaluated using a ProcessExecutionContext. Thus, the expression “Person’s age” returns the age in the current profile when evaluated against the current scenario execution context. You can also query the ProcessExecutionContext explicitly for the current user profile, request, and so on (see an example of this below).

The Action interface has an initialize method that is called when the action is first created. This method takes a Map of parameters. The keys in the Map are the String parameter names; the values are the Expression objects representing parameter values. The initialize method should store these parameter expressions for later evaluation. For example, suppose you create a scenario that contains a LogAction, with parameters configured as follows: logString is simply the string “this is a test,” and logInteger is the expression “Person’s age.” When the scenario is created, the action’s initialize method is called with a Map which contains two key/value pairs: "logString"/Expression, representing the string “this is a test,” and "logInteger"/Expression, representing “Person’s age.”

When the action is executed on a particular user or collection of users, one of its execute methods gets called. The first version of the execute method takes a ProcessExecutionContext. The action may use this context object to evaluate its parameter Expressions, or it may obtain information directly from the context (for example, the context contains the current DynamoHttpServletRequest, which can be used to evaluate any Nucleus expression, among other things).

The second version of the execute method takes an array of ProcessExecutionContext objects. It is called when several scenario instances are traveling through the scenario at the same time; typically, it just calls the first version of the method for each of the given context objects.

The class atg.process.action.ActionImpl is an abstract Action implementation that is provided to make implementing simple actions easier. It provides methods for storing, retrieving, and evaluating parameter Expressions so you do not have to re-implement the same logic for each action. It also implements both versions of the execute method in terms of an abstract method, executeAction, which takes a single ProcessExecutionContext. Thus, to implement your action, you need to implement only the methods initialize and executeAction.

The LogAction example below inherits from ActionImpl and demonstrates its use. In its initialize method, it uses the method storeRequiredParameter to store the Expressions for parameters logString and logInteger. Then, in the executeAction method, it uses the method getParameterValue to evaluate the parameter expressions and print them out. In addition, the test action prints out all of the values available from the context.

package test.scenario;
import java.util.Map;
import atg.servlet.DynamoHttpServletRequest;
import atg.process.ProcessExecutionContext;
import atg.process.ProcessException;
import atg.process.action.ActionImpl;
/**
 * Custom scenario action that logs its parameters.
 *
 * @version $Revision$
 **/
public class LogAction extends ActionImpl {
  //-------------------------------------
  // Constants
  //-------------------------------------
  /** parameter: logString **/
  public static final String PARAM_LOG_STRING = "logString";
  /** parameter: logInteger **/
  public static final String PARAM_LOG_INTEGER = "logInteger";
  //-------------------------------------
  // ActionImpl overrides
  //-------------------------------------
  //-------------------------------------
  /**
   * Initializes the action with the given parameters. The keys in
   * the parameter Map are the String parameter names; the values are
   * the Expression objects representing parameter values.
   *
   * @exception ProcessException if the action could not be properly
   * initialized - for example, if not all of the required parameters
   * are present in the Map
   **/
  public void initialize(Map pParameters)
    throws ProcessException
  {
    storeRequiredParameter(pParameters, PARAM_LOG_STRING, String.class);
    storeRequiredParameter(pParameters, PARAM_LOG_INTEGER, Integer.class);
  }
  //-------------------------------------
  /**
   * Executes this action in the given single process execution
   * context. Called by both of the execute methods.
   *
   * @exception ProcessException if the action can not be executed
   **/
  protected void executeAction(ProcessExecutionContext pContext)
    throws ProcessException
  {
    // Get our request so that we can log stuff.
    DynamoHttpServletRequest request = pContext.getRequest();
    // use the context to evaluate the action's parameters
    String str = (String) getParameterValue(PARAM_LOG_STRING, pContext);
    Integer num = (Integer) getParameterValue(PARAM_LOG_INTEGER, pContext);
    request.logInfo("string value = " + str);
    request.logInfo("integer value = " + num);
    // the following objects are available from the context
    request.logInfo("scenario instance = " + pContext.getProcessInstance());
    request.logInfo("subject = " + pContext.getSubject());
    request.logInfo("message = " + pContext.getMessage());
    request.logInfo("request = " + request);
    request.logInfo("response = " + pContext.getResponse());
  }
  //-------------------------------------
}

Adding Custom Actions For Scenario : ATG



Adding Custom Actions


You can extend the Scenario Manager to support custom scenario actions. The procedure has the following steps:

1.Add the new action to the Scenario Manager configuration file.

2.Implement the action interface (atg.process.action.Action).

The example in this section adds an action that simply logs some information about its parameters and its evaluation context to the Dynamo information log. Such an action is very handy for debugging purposes, among other things, and it illustrates some of the general principles of custom scenario actions.


Adding the Action to the Scenario Manager Configuration File


The Scenario Manager’s configuration file is located in your config path at /atg/scenario/scenarioManager.xml. You can add a new action to this configuration by creating a file with the same name in your localconfig directory. Below is an example of a scenarioManager.xml file that you would have to define in order to add the test action.

<?xml version="1.0" encoding="ISO-8859-1" ?>

<!DOCTYPE process-manager-configuration
        PUBLIC "-//Art Technology Group, Inc.//DTD Process Manager//EN"
        'http://www.atg.com/dtds/processmanager/processmanager_1.0.dtd'>

<process-manager-configuration>

  <action-registry>
    <action>
      <action-name>
        Log Info
      </action-name>
      <action-class>
        test.scenario.LogAction
      </action-class>
      <description>
        prints out information about the action's context and parameters
      </description>
      <action-execution-policy>
        individual
      </action-execution-policy>
      <action-error-response>
        continue
      </action-error-response>
      <action-parameter>
        <action-parameter-name>
          logString
        </action-parameter-name>
        <action-parameter-class>
          java.lang.String
        </action-parameter-class>
        <required>
          true
        </required>
        <description>
          a string value to evaluate and display
        </description>
      </action-parameter>
      <action-parameter>
        <action-parameter-name>
          logInteger
        </action-parameter-name>
        <action-parameter-class>
          java.lang.Integer
        </action-parameter-class>
        <required>
          true
        </required>
        <description>
          an integer value to evaluate and display
        </description>
      </action-parameter>
    </action>
  </action-registry>

</process-manager-configuration>


The action specification contains the action’s name, its class (which must implement the atg.process.action.Action interface), and its description. In addition, you must set two other important properties for your action in these tags:

1.<action-execution-policy>

2.<action-error-response>



Adding Parameters to a Scenario Action


You can also specify any number of action parameters for an action. Each parameter declares a name and the parameter value type. Our test action, for example, has two parameters, one of type String (with name “logString”), and another of type Integer (with name “logInteger”).

To require users to specify a given parameter, include a <required> tag for that parameter and set it to true (see the example above). This tag is optional. If you include it, the ACC displays an error message if users do not specify the parameter.

Users can specify action parameters as either explicit values or expressions when they create scenarios in the ACC. For example, for a parameter of type Integer, they can type an explicit integer value, such as “249,” or select an expression that evaluates to an integer, such as “Person’s age.” When the system executes the action, it evaluates the parameter expressions in the current scenario context; thus the expression “Person’s age” is evaluated to the age in the profile of the person going through the scenario.

For action parameters of type String or String[], you can include the optional tags <action-parameter-repository-name> and <action-parameter-repository-item-type>. Without these tags, users must manually type the repository ID for the item they want when they fill in a parameter. With these tags, however, the ACC displays a dialog box from which users can choose the appropriate item by its display name. The system then passes the repository ID to the action. The following example is from the Give Promotions action in Commerce; it shows how the Promotions action parameter is set up to use these tags:

<action>
.....
<action-parameter>
        <action-parameter-name>
          promotions
        </action-parameter-name>
        <action-parameter-class>
          java.lang.String[]
        </action-parameter-class>
        <action-parameter-repository-name>
          ProductCatalog
        </action-parameter-repository-name>
        <action-parameter-repository-item-type>
          promotion
        </action-parameter-repository-item-type>
        <description>
          the promotions to be added to the profile
        </description>
      </action-parameter>
.....
</action>


Implementing the Action Interface:



1.atg.process.expression.Expression

2.atg.process.action.Action

3.atg.process.action.ActionImpl

4.atg.process.ProcessExecutionContex





Thursday, April 18, 2013

Deployment Scope & Difference Between Full Deployment and Incremental Deployment in BCC : ATG


Deployment Scope


The scope of asset deployment to a target site is determined by the type of deployment that you choose.

Two deployment type options are available:

1. Full Deployment

2. Incremental Deployment

Your decision to perform a full or incremental deployment can depend on various factors, such as the number and type of assets to deploy, the frequency of deployment, and the reason for deployment.


Difference Between Full Deployment & Incremental Deployment:



Full Deployment


A full deployment comprises two steps:

1. All assets are deleted from the target site.

2. All changed assets from the deployed project, and all appropriate existing assets, are deployed to the site.

Full deployments can be time consuming and resource intensive if the site has a large number of assets. However, it is especially useful (and sometimes necessary) to refresh assets when they are modified directly or are corrupt. It is also practical for small sites with few assets, as it can be performed relatively quickly.



Note: You can configure a full deployment to delete only certain file assets from a VFS with the SelectiveDeleteVFSService. This VFS lets you indicate explicitly which files to delete from the local file system during deployment.



Incremental Deployment


An incremental deployment only updates the site with asset changes from the deployed projects; these changes include add, update, and/or remove operations. This type of deployment is more efficient than a full deployment, especially when very few site assets changed since the previous deployment.





Monday, April 1, 2013

Sending E-mail to Users Without Profiles : ATG



In some situations, you may want to send e-mail to a user or a group of users who have not yet registered at your site and who do not have profiles. For example, you might want to send a gift certificate to a group of e-mail addresses promising a promotion if the recipients register at your Web site. To send e-mail to a user without a profile, use the TemplateEmailInfoImpl.messageTo property. You can set the messageTo property globally, or in a JSP or JHTML file. If you set it globally, messageTo overrides the emailAddress property specified in the e-mail template. To set messageTo in a JSP file, add the following lines to the JSP template:

<dsp:setvalue paramvalue="message.profile.giftEmailAddress"
 param="messageTo"/>
<setvalue param="fillfromTemplate" value="true">
Here is the same example in JHTML:

<setvalue param="messageTo"
 value="param:message.profile.giftEmailAddress">
<setvalue param="fillfromTemplate" value="true">

This setting is local to a specific template and does not affect other mailings. The fillfromTemplate parameter forces the sender to override any property set in the template file.

Using the TemplateEmailSender Class

You can also send e-mail to e-mail addresses that do not have matching profiles by specifying the e-mail addresses as an array of Strings. In the same way that you can send e-mail to a profile group, you can programmatically specify a list of e-mail addresses:

Object []recipients = {"bill@example.com", "sam@example.com"};
TemplateEmailSender.sendEmailMessage(TemplateEmailInfo, recipients);

In this example, the TemplateEmailSender component checks each element in the recipients [] and if the element is of type String , the TemplateEmailSender sends e-mail to the e-mail address.

You can also mix and match Profile objects with String based e-mail addresses when calling TemplateEmailSender.sendEmailMessage:


Object[] profileRecipients = profileGroup.getGroupMembers();
Object[] emailRecipients = {"bill@example.com", "sam@example.com"};
Object[] recipients = addArrays(profileRecipients, emailRecipients);
TemplateEmailSender.sendEmailMessage(TemplateEmailInfo, recipients);




Creating a Targeted E-mail Template : ATG



Creating a Targeted E-mail Template:




The page template for your targeted e-mail is specified by the templateURL property of the TemplateEmailInfoImpl object. You create this template like any other page. Because the template page is passed to the standard ATG servlet pipeline, it can include ATG servlet beans and additional JHTML or JSP tags.

Here is a sample JSP targeted e-mail template. It displays a few profile attributes and contains a targeting servlet bean. Assuming the targeting rules used in the TargetingForEach servlet bean’s targeter service depend on the attributes of the Profile component, the targeting results displayed in the e-mail message will be different for each profile.

<dsp:importbean bean="/atg/userprofiling/Profile"/>
<p>Dear <dsp:valueof bean="Profile.firstName"/>
<dsp:valueof bean="Profile.lastName"/>,
<p>Thank you for your order! It has been shipped today to:
<blockquote><pre>
<dsp:valueof bean="Profile.address"/><br>
<dsp:valueof bean="Profile.city"/>, <dsp:valueof bean="Profile.State"/>
<dsp:valueof bean="Profile.zipCode"/>
</pre></blockquote>

<p>Since your last order, we've introduced some great new products. If you enjoy
your new <dsp:valueof bean="Profile.lastProductShipped"/>, you may also be
interested in ordering some of these great widgets:<p>

<dsp:droplet name="/atg/targeting/TargetingForEach">
  <dsp:param bean="/targeters/WidgetTargeter" name="targeter"/>
  <dsp:oparam name="output">
    <dsp:valueof param="element.name"/><br>
  </dsp:oparam>
</dsp:droplet>

<p>Thank you for shopping with us.
<p>Sincerely,
The Customer Service Team
help@example.com
http://www.example.com


Here is the same example in JHTML:



<importbean bean="/atg/userprofiling/Profile">
<p>Dear <valueof bean="Profile.firstName"></valueof>
<valueof bean="Profile.lastName"></valueof>,
<p>Thank you for your order! It has been shipped today to:
<blockquote><pre>
<valueof bean="Profile.address"></valueof><br>
<valueof bean="Profile.city"></valueof>, <valueof bean="Profile.State"></valueof>
<valueof bean="Profile.zipCode"></valueof>
</pre></blockquote>

<p>Since your last order, we've introduced some great new products. If you enjoy
your new <valueof bean="Profile.lastProductShipped"></valueof>, you may also be
interested in ordering some of these great widgets:<p>

<droplet bean="/atg/targeting/TargetingForEach">
  <param name="targeter" value="bean:/targeters/WidgetTargeter">
  <oparam name="output">
    <valueof param="element.name"></valueof><br>
  </oparam>
</droplet>

<p>Thank you for shopping with us.

<p>Sincerely,
The Customer Service Team
help@example.com
http://www.example.com
Note that if your template page contains links to other URLs on your site, you must specify them as absolute URLs; otherwise the e-mail recipients will not be able to access the linked pages. Use the full http://server:port/... form of the URL. For example, in JSP code:

<dsp:img src="http://myserver:80/images/logo.gif">
<dsp:a href="http://myserver:80/help/index.html">help</dsp:a>
In JHTML:

<img src="http://myserver:80/images/logo.gif">
<a href="http://myserver:80/help/index.html">help</a>
The following examples will not work, because they use relative URLs. In JSP code:

<dsp:img src="images/logo.gif">
<dsp:a href="help/index.html">help</dsp:a>
In JHTML:

<img src="images/logo.gif">
<a href="help/index.html">help</a>

Specifying E-mail Fields in the Template

By default, the Personalization module takes the values for various fields of an e-mail message from properties of the TemplateEmailInfoImpl object. This behavior means that all messages using the same object will have identical properties. For example, suppose the value of the messageSubject property of the TemplateInfoImpl component is “Hello”. All e-mail messages created by this component will contain the subject line “Hello”.

You can override the values of these properties in a specific e-mail template by doing the following:


In the template, include parameters with the same names as the corresponding TemplateEmailInfoImpl properties.

Set the fillFromTemplate value of the TemplateEmailInfoImpl object to true.

For example, you can set a different subject line for a specific mailing by including a statement as follows in the template for that mailing:

JSP example:

<dsp:setvalue value="Your order has shipped" param="messageSubject"/>

JHTML example:

<setvalue param="messageSubject" value="Your order has shipped">

Because these parameters are evaluated for each message individually, they can include dynamic content. For example, you could set the message subject as follows.

JSP example:

<dsp:setvalue value='<%="Order " + request.getParameter("order.id")+
" has shipped"%>' param="messageSubject"/>

JHTML example:

<setvalue param="messageSubject"
  value="Order `request.getParameter("order.id")` has shipped">

There are seven parameters that you can use in this way to override the corresponding TemplateEmailInfoImpl properties:


1.mailingName

2.messageFrom,

3.messageTo

4.messageReplyTo

5.messageSubject

6.messageCc

7.messageBcc

You can use any combination of these parameters in an e-mail template; if any of these parameters is not set, the system uses the corresponding property value instead.

For example, you could globally set the messageCc property to Cc yourself, but you could override this property if you wanted to Cc or Bcc other people to make them aware of a particular e-mail campaign. The messageCc and messageBcc parameters are defined as a string of e-mail addresses separated by commas. For example, you could add the following lines to a template file.

JSP example:

<dsp:setvalue value=lewis@example.com,everyone@example.com
 param="messageCc"/>
<dsp:setvalue value=management@example.com,bob@example.com
 param="messageBcc"/>

JHTML example:

<setvalue param="messageCc" value=lewis@example.com,everyone@example.com>
<setvalue param="messageBcc" value=management@example.com,bob@example.com>

Note: Property values you set through an e-mail template are not persisted to the database. Only the values that are set in the TemplateEmailInfoImpl object are persisted.



Popular Posts