The UDTT Smart server-side data collectors provide API to help collect the data from server-side to record visit or transaction data into database. Following is the server-side collector mechanism:
Following is the general steps for the server collector:
1 Add smart data collector handler in the UDTT channel driver. In file btt.xml, configure the following smart collector handler and the configuration file path.
The SmartCollectorHandlerfield is the class of the smart collector handler. It should extend class com.ibm.btt.channel.AbstractSmartCollector and implement the processResult (Map<String> result) method. This method process the parameter result, and then return the Boolean value according to user-defined logic. If the method return true, it performs the smart collecting; else if it return false, it will not collect the data. The smartCollectorConfigFilefield is the smart collector configuration file path.
2 When server starts, it initiates smart data handler policy rule by element factory. The configured smartCollectorConfigFile file contains the global configuration: sampling rule, the global DAO pattern: JMS or general smart DAO. It also defines the server-side smart collector transactions, transaction collector sampling rule, transaction-related dynamic request data extension. Following is the sample code:
The service class should extend the class com.ibm.btt.channel.ruleprovider.java.JavaCodeRuleProviderService, which is included in the bttruleprovider.jar. The actionType should be behavioror visit. Other value is not accepted. The extendBeanshould be predefined. If the actionType is behavior, the class should extend the class com.ibm.btt.channel.smart.data.BehaviorLog. If the actionType is visit, the class should extend the class com.ibm.btt.channel.smart.data.VisitLog.
3 The operation name or processor id are used as transactionID, when the request comes, it gets the operation name or processor id to match. If it matches the transactionID, it performs the smart collecting according to the rule.
4 Smart data handler policy support global rule and transaction rule, the customers can add their owner business logic in it. If the transaction rule is configured, it collects according to transaction rule; if the transaction rule is not configured, it checks the global rule; The collector performs collecting even if the transaction rule and global rule are neither configured.
For the visit server collector, the actionType should be set as visit. The transactionID field should be set the sign operation name.
Note If the actionType is visit, one entry that valued as userId must be defined in the datamap. In the previous sample codes, the entry key is name, which should be mapped in the data in the request web page; the entry value is userId, which is used to map into the visitLog bean.
Smart data collector supports global rule and transaction rule. If the transaction rule is configured, it collects according to transaction rule; if the transaction rule is not configured, it checks the global rule; The collector performs collecting even if the transaction rule and global rule are neither configured. Refer to the general steps in Server collector, and configure the rule in global level or transaction level.
The rule service class should extend the class com.ibm.btt.channel.ruleprovider.java.JavaCodeRuleProviderService, which is included in the bttruleprovider.jar. The rule service class should implement the method public Map<String> checkRule(Map<String> params). This method is invoked by the smart collector handler class to check if the transaction data should be collected. In the definition of the method public Map<String> checkRule(Map<String> params), you can get the extension data that defined in the smart dynamic datamap to define the sampling rule as following code:
You can also get the session context data to define the sampling rule as following code:
public class IsVIPRuleService4FVT extends JavaCodeRuleProviderService { public Map<String> checkRule(Map<String> params) { System.out.println("IsVIPRuleService4FVT Checking the channel rule"); Map<String> result=new HashMap<String>(); Context sessCtx=(Context) params.get(ChannelConstant.SESSION_CTX); String userId=(String)sessCtx.tryGetValueAt("userId"); boolean isVIP=false; System.out.println("======userId="+userId); if(userId.equals("user01")||userId.equals("user02")){ isVIP=true; } if (isVIP) result.put( "collect" , Boolean.TRUE); else result.put( "collect" , Boolean.FALSE); return result; }
The userId field should be the session context data which is defined in the session context definition file. It should also be set value previously as following sample code:
Dynamic extension data map for the server collector
Smart data collector supports dynamic map request data for visit and behavior. Users can collect extension data besides the basic collected data. For example, when user executes the transfer transaction, you can configure the basic behavior data, including userId, behavior type, service name, behavior time. By the dynamic map, you can collect more detailed data about the transfer transaction, such as accountFrom, accountTo, amount. Refer to the general steps in Server collector, and configure the map data as following codes:
1 The “entry” list in the dataMap map should be consistent with the id of the request page.
2 After the behavior data including the extension data is collected, a record is saved in the BEHAVIOR_LOG table; two records will also be saved in the BEHAVIOR_EXT table, the NAME field are the value of the entry, the DATA field are the value of the entry.
