ATG Made Easy - part 5

ATG Personalization Features:

One of the power features of ATG is the personalization module, here is a quick list of the available features:

1) Internal and External User Profiles:

The default external user profile repository is /atg/userprofiling/ProfileAdapterRepository,
which is defined by the userProfile.xml file located in <ATG9dir>\DPS\config\profile.jar. Each
ATG application that adds properties to the external user profile stores its userProfile.xml file in an
ExternalUsers sub-module.
Internal profiles are stored in the /atg/userprofiling/InternalProfileRepository, defined by the
internalUserProfile.xml file in <ATG9dir>\DPS\InternalUsers\config\config.jar.
A parallel set of database tables also exists for internal user profiles. Where the user item in the
ProfileAdapterRepository references the dps_user table, the user item in the
InternalProfileRepository points to a dpi_user table, and so on.

You can extend/replace and customize the userProfile.xml using the same way as any repository.

In ATG, you can configure the profile to use SQL or LDAP or both.
By changing : /atg/userprofiling/ProfileTools into :
profileRepository=/atg/adapter/ldap/LDAPRepository

The LDAP is based on view, object and classes:
<!-- user view -->
<view name="user" default="true">
.....
<!-- object classes -->
<object-class>top</object-class>
<object-class>person</object-class>
<object-class>organizationalPerson</object-class>
<object-class>inetorgPerson</object-class>
<!-- properties -->
<property name="login" ldap-name="uid" data-type="string" required="true">
<attribute name="unique" value="true"/>
</property>
<property name="password" ldap-name="userpassword" data-type="string"
required="true"
editor-class="atg.beans.PasswordPropertyEditor"/>

Whenever a user accesses a site that uses the Personalization module, two different mechanisms are used
to track the user’s actions:
• A session is created for the user, and is maintained either through a cookie or through
URL rewriting.
• The user is associated with a profile.
To change the secret key that the Personalization module uses to hash the user ID cookie, edit the
following property of /atg/userprofiling/CookieManager:
cookieHashKey=

Profile Form Handlers:

-handleCreate: Creates a new permanent profile and sets the profile attributes to the values entered in the form.
-handleUpdate Modifies the attributes of the current profile.
-handleLogin Uses the login and password values entered by the user to associate the correct profile with that user.
-handleChangePassword Changes the password attribute of the profile to the new value entered by the user.
-handleLogout Resets the profile to a new anonymous profile and optionally expires the current session.


Access Control
Control access to some or all of the pages on the site.
AccessControlServlet (/atg/userprofiling/AccessControlServlet):

Configurations:
$class=atg.userprofiling.AccessControlServlet
enabled=true
# Nucleus path of the Profile object
profilePath^=ProfileRequestServlet.profilePath
# List of mappings between paths and AccessController objects. If a
# path refers to a directory, all the documents in that directory and
# its subdirectories will be protected by the given AccessController.
accessControllers=\
/docs/members=/your/path/MemberAccessController,\
/docs/members/preferred=/your/path/PreferredMemberAccessController
# List of "access allowed" event listeners
# accessAllowedListeners=
# List of "access denied" event listeners
# accessDeniedListeners=
# The URL to redirect to if access is denied. If the AccessController
# supplies its own deniedAccessURL, it will overwrite this value.
deniedAccessURL=http://yourserver/noaccess.html


*RuleAccessController
This implementation of AccessController performs access control based on a set of rules, specified via the service’s ruleSetService property. For example, suppose there is a RuleSetService named
FemaleRuleSetService, configured with the following rule set:
<ruleset>
<accepts>
<rule op=eq>
<valueof target="Gender">
<valueof constant="female">
</rule>
</accepts>
</ruleset>
Set the ruleSetService property of the Access Controller to point to
FemaleMembersRuleSetService. The user will be allowed access only if she is in the Female profile
group. Here is the example configuration:
$class=atg.userprofiling.RuleAccessController
enabled=true
# Rules used to determine whether access should be allowed
ruleSetService=/your/path/rules/FemaleRuleSetService
# URL to redirect to if access is denied
deniedAccessURL=http://yourserver/femaleAccessOnly.html


2) Targeting Content:

Creating Rules for Targeting Content:
Example:
<rule op=eq name="Rubber sector">
<valueof target="industrySector">
<valueof constant="rubber">
</rule>
Type:
Accept Rules
Reject Rules
Sorting directives
<ruleset>
<accepts>
<rule ...> ... </rule>
...
</accepts>
<rejects>
<rule ...> ... </rule>
...
</rejects>
<includes>
<ruleset src=...> ... </ruleset>
...
</includes>
<sortby>
<sortbyvalue ...>
...
</sortby>
</ruleset>


Setting Up Targeting Services:
To set up a RuleSetService for your rule set, create an atg.targeting.RuleSetService component.
This component can reference a rules file, or it can itself include your targeting rules as a property

So either
-rulesFilePath:If your Rule Set Service refers to a rules file, set this property to the file path of the rules file. This path can
be an absolute path or a relative path starting from your <ATG9dir>/home directory.
-ruleSet=xml rules structure

** Targeter Example: calling slot from targeter

<dsp:droplet name="/atg/targeting/TargetingFirst">
<dsp:param name="targeter" bean="/atg/registry/slots/aricleSlot"/>
<dsp:param name="howMany" value="1"/>
<dsp:oparam name="output">
<dsp:a href="articleDetails.jsp">
<dsp:param name="itemId" param="element.id"/>
.....
.....other retrived parameters ....
.....
</dsp:a>
</dsp:oparam>
</dsp:droplet>

Targeted E-mail:
You can use the Targeted E-mail services included with the Personalization module to compose and deliver e-mail using the same profile groups and targeting rules you use to deliver content on your Web site.

You create targeted e-mail using the:
atg.userprofiling.email.TemplateEmailInfoImpl class.
This class draws the message body of an e-mail from a page template, invokes a MessageContentProcessor component to process the content, and then passes the resulting JavaMail object to the TemplateEmailSender component, which sends the message. The properties of a TemplateEmailInfoImpl object store values that are specific to an individual e-mail campaign, so you should create a separate instance of this class for each campaign.
*key properties of the TemplateEmailInfoImpl class:
templateURL
messageFrom
messageTo
contentProcessor:MessageContentProcessor responsible for processing the message content; Default: /atg/userprofiling/email/HtmlContentProcessor another valid value is SimpleContentProcessor
...

The HtmlContentProcessor can be further configured according to the needed formatting.


3) Scenario Module:
Scenarios are event-based i.e. what does user/system do? but targeters are knowledge-based i.e. what does the user info/snapshot contain.

The configuration file scenarioManager.xml is the place where information common to all scenario servers is specified. This file uses the Process Manager DTD, located in
<ATG9dir>\DSS\lib\classes.jar. The scenarioManager.xml file
A cluster of ATG servers must always contain the following:
• exactly one process editor server
• zero or more global scenario servers
• zero or more individual scenario servers

The main Nucleus component responsible for scenario operations is located at /atg/scenario/ScenarioManager. To examine the scenarios handled by this service, point your Web browser to the ATG Dynamo Server Admin page at:
http://localhost:port/dyn/admin/nucleus/atg/scenario/ScenarioManager/

You can defining Access Control for a Scenario as well..
You can bound the scenario to events like :
Collective events:
• InboundEmail Event
• Shutdown Event
• Startup Event
• GSAInvalidation Event
Individual events:
• Login Event
• Logout Event
• Register Event
• AdminRegister Event
• StartSession Event
• EndSession Event
......etc.

The scenario is componsed of actions , Scenario actions are implementations of the atg.process.action.Action interface or direct extends ActionImpl class.
The main methods are:
-initialize (map of parameters)
-configure (Config object) , you can cast to your customized configuration object according to the action definition xml; the config object extends Generic Service and contains getters and setters for all configuration elements.
-executeAction(ProcessExecutionContext context)
Where you can have access to request, response, user, events, parameters, properties set by admin for all users ...etc...

Configuration file : ScenarionManager.xml

<action-name>
</action-name>
Yes The logical name of the action as passed to an
action handler.
<action-class>
</action-class>
Yes A Java class that is an implementation of the atg.process.action.Action interface.
<action-configuration>
</action-configuration>
No The Nucleus path of the action’s configuration file.
Most of other elements are optional only action name and class are required.

Default scenario actions:
• Modify Action
• Set Random Action
• Redirect Action
• FillSlot Action
• EmptySlot Action
• Disable Scenario Action
• Record Event Action
• Record Audit Trail Action
• Filter Slot Contents Action
• Add Marker To Profile Action
• Remove All Markers From Profile Action
• Remove Markers From Profile Action
• Add Stage Reached Action
• Remove Stage Reached Action
• E-mail-Related Actions: EmailNotify and SendEmail



4) Using Slots :

Slots are containers that you can use to display and manage dynamic items on your Web site. You use targeting servlet beans to include slots in site pages, and you use scenarios to fill them with content.
Slots are components of class atg.scenario.targeting.RepositoryItemSlot or
atg.scenario.targeting.Slot. A slot component must have a Nucleus address in the folder
/atg/registry/Slots/.
You can create slot components in two ways:
• By manually creating a .properties file
• Through the slot wizard in the ACC

The following is an example of a .properties file for a slot component of class
atg.scenario.targeting.RepositoryItemSlot:
$class=atg.scenario.targeting.RepositoryItemSlot
$description=displays fund news to brokers
$scope=session
generation=0
itemDescriptorName=news
maxRenderSize=3
ordering=1
persistent=true
repositoryName=News
retrieval=1

Most important are:
repository name = source of content, itemDescriptorName also.
The Event Generation option corresponds to generation (property of type int) in the slot component .properties file. For Never, specify 1. For When Empty, specify 0.
Item retrival: 0=static ; 1=rotating ; 2=destructive (displayed only once then removed)
ordering : 0= shuffle, 1=random

A lot of other features still exist in this module.

Reference: ATG Platform documentation set : Version 9.1 - 7/31/09