Oracle ATG – Scenarios & Execution

By | December 23, 2013

UNDERSTANDING ATG SCENARIOS AND EXECUTION

The ATG Scenario module is primarily an extension or more sophisticated version of its personalization module. The ATG Scenario module enables business users / marketers with advanced targeting features and functionalities that helps them look @ the customer engagement and CRM from long-term perspective.

Scenario comprises of user’s interaction with the site, any event that occurs based on user’s interaction with the site, trigger conditions, associated business rules, and the actions that need to take place e.g. provide $10 off for registering online. A chain of scenarios can be created based on customer life-cycle and customer touch-point interactions. Events in the ATG platform are in form of JMS messages.

Business users can create scenarios such as fire and forget – scenarios that may trigger once in life-time of each customer e.g. provide a free movie pass for registering online.

Also, the scenarios can be as complex as the business user wants to take the personalization to into customer’s interaction with the products and services.

One of the key factors that make scenarios special is the “element of time” – as I said earlier – fire and forget. The engine will wait for the user to take some action to trigger the scenario and take the user experience to next level by providing the user with targeted content in future.  Scenarios are more like workflows in nature, design, implementation, and execution.

Let us get into the depth of understanding the scenario engine/server that carries out several tasks based on user’s state, profile, marketing data, and many other variables.

Scenarios are pre-compiled on server start-up from the scenarios XML file into the scenario state machine. In order to keep track of where in the scenario the users are, the scenario server must maintain some state for every individual going through the scenario—most notably, it must maintain the individual’s location in the scenario.

Maintaining the per-user scenario state is complicated by forking. The example above shows that, because of forking, a user can be in two different places in the scenario at once, waiting for two different events to occur. A much more complicated scenario might have many forks, and forks inside forks, so that keeping track of all the states associated with just a single user could become quite problematic. To simplify the matter, the scenario server does not actually attempt to execute scenarios the way they are defined. Instead, it transforms each scenario into an equivalent scenario state machine (SSM). This behavior requires an additional processing step when the scenario is first created and started, but it provides some important advantages.

The main virtue of the scenario state machine is that a given individual is always in exactly one SSM state, and progresses through a strictly linear sequence of states with no forking. In addition, the state machine is constructed in a way that provides various useful guarantees concerning its structure.

Scenario Server - Interaction

Where can you find the Scenario files?

When a scenario is created and saved in the ACC, the scenario definition file is stored in the scenario register located in the nucleus path (/atg/registry/data/scenario) - Look for the nucleus path inside the config.jar file located in the folder <ATGDIR>/DCS/config/config.jar

You can find the SDL DTD inside the classes.jar file which you can find in the <ATGDIR>/DSS/lib/classes.jar (\atg\scenario\definition\sdl.dtd)

Also, you will find the file named sdltopdl.xsl (Stylsheet) – this file translates SDL to PDL (Process Definition Language).

Scenario Server - SDL

 EXAMPLE Scenario Definition Language (SDL) FILES

SHOPPINGPROCESS.SDL

<?xml version=”1.0″ encoding=”UTF-8″?>
<!DOCTYPE process SYSTEM “dynamosystemresource:/atg/dtds/pdl/pdl_1.0.dtd”>
<process author=”admin” creation-time=”1084559224627″ enabled=”false” last-modified-by=”admin” modification-time=”1084559259889″>
<segment migrate-subjects=”true”>
<segment-name>Segment 1</segment-name>
<!–================================–>
<!–== Business Process Stage Reached businessProcessName is ShoppingProcess –>
<!–================================–>
<event id=”1″>
<event-name>atg.business.process.stage.reached</event-name>
<filter construct=”event-property-filter” operator=”eq”>
<event-property construct=”event-property”>
<property-name>businessProcessName</property-name>
</event-property>
<constant>ShoppingProcess</constant>
</filter>
</event>
<!–================================–>
<!–== Record event Business Process Stage Reached in dataset Shopping Process Stage Reached Dataset –>
<!–================================–>
<action id=”2″>
<action-name>recordEvent</action-name>
<action-param name=”dataset”>
<constant>/shoppingprocess.xml</constant>
</action-param>
</action>
</segment>
</process>

VIEWITEM.SDL

<?xml version=”1.0″ encoding=”UTF-8″ standalone=”no”?>

<!DOCTYPE scenario
SYSTEM
“dynamosystemresource:/atg/scenario/definition/sdl.dtd”>

<scenario modification-time=”964040379145″ enabled=”false” author=”admin” creation-time=”955071601000″>
<segment>
<segment-name>Views an Item</segment-name>
<!–================================–>
<!–== Views any item  –>
<!–================================–>
<event id=”1″>
<event-name>atg.dps.ViewItem</event-name>
</event>
<!–================================–>
<!–== Record event Views Item in dataset DPS View Item  –>
<!–================================–>
<action id=”2″>
<action-name>recordEvent</action-name>
<action-param name=”dataset”>
<constant>/viewitem.xml</constant>
</action-param>
</action>
</segment>
</scenario>

 

Let me know what you think about this article