Monday, December 23, 2013

Session Management in ATG Applications : ATG



Note: This is about session management in ATG applications running on third-party application servers

The J2EE specification defines that each web application has its own session object and any attributes added to the session are only accessible from within that web application. The application server is entirely responsible for managing session life cycles; it generates a unique session ID, creates the session, invalidates it, fails it over, etc. An “ATG session” refers to session-scoped components Also, keep in mind that Nucleus components have a tree structure, and can include multiple scopes, with each scope being rooted at a particular component. The root for session-scoped components is /atg/dynamo/servlet/sessiontracking/GenericSessionManager/sessionid/ where sessionid is generated by the application server.


Sharing Session Information Among ATG Applications


You can run multiple ATG applications in the form of WAR files within a single EAR. In this case, you should share session-scoped Nucleus components so that your application will always have access to the same instance of session scoped components. By default, J2EE servers hand out different session objects in each web application visited, even if all requests came from the same browser. Sharing sessions across ATG applications ensures that you can build a J2EE application consisting of multiple WAR files in a single EAR, and each WAR has access to the same session-scoped components. Note that you should never run more than a single ATG EAR per application server instance.

When multiple web applications exist in the ATG EAR file, one of them must be designated as the parent application. Being the parent means that that application’s session ID is used as the basis for creating the ATG session scope root.

By default, ATG makes the <ATG10.2dir>\DafEar\base\j2ee-components\atg_bootstrap.war file the parent web application. The parent context path is /dyn. No additional configuration is required to use this, but your web applications should define the atg.session.parentContextName and atg.dafear.bootstrapContextName parameters in their web.xml to point to the parent web-application as shown:


<context-param>
   <param-name>atg.session.parentContextName</param-name>
   <param-value>/dyn</param-value>
</context-param>
<context-param>
   <param-name>atg.dafear.bootstrapContextName</param-name>
   <param-value>/dyn</param-value>
   <description>The name of the DAF bootstrap WAR context.</description>
</context-param>

The context path the context-param points to must be for a WAR file with the SessionNameContextServlet defined in its web.xml:

<servlet>
   <servlet-name>SessionNameContextServlet</servlet-name>
   <servlet-class>atg.nucleus.servlet.SessionNameContextServlet
   </servlet-class>
</servlet>

Note that there can be only one parent web application specified per EAR file. Therefore, if you change the parent application, be sure to set the context-param to the same values in all web.xml files within your EAR file:

<context-param>
   <param-name>atg.session.parentContextName</param-name>
   <param-value>/portal</param-value>
</context-param>

Note: This information applies only to session-scoped Nucleus components, and does not affect HTTP sessions obtained using atg.servlet.ServletUtil.getDynamoRequest(request).getSession(), which retain a context particular to the current web application.


Managing User Sessions


You can manage user sessions from the Dynamo Component Browser for debugging or administrative purposes. To access the Session Manager, click through the hierarchy:

/atg/dynamo/servlet/sessiontracking/

Click GenericSessionManager to view sessions. Choose the selection criteria, then click the View button. Click an individual session to see its properties.



Switching Databases : ATG


In many database-dependent applications, you may want to make changes in an offline database and then switch over your live application so that the inactive database becomes the live database. ATG’s switching facility is based on a class named atg.service.jdbc.SwitchingDataSource. You can use a SwitchingDataSource in place of a regular data source (such as atg.service.jdbc.MonitoredDataSource)

The SwitchingDataSource can be switched between two or more underlying DataSources. All DataSource method calls are passed through to the DataSource specified by the currentDataSource property of the SwitchingDataSource. Note that each DataSource that the SwitchingDataSource points to must be of class atg.nucleus.JNDIReference, with a JNDIName property that points to an application server data source.


Configuring a SwitchingDataSource


$class=atg.service.jdbc.SwitchingDataSource
#
# A map from data source names to data sources
#
dataSources=\
     DataSourceA=/atg/commerce/jdbc/ProductCatalogDataSourceA,\
     DataSourceB=/atg/commerce/jdbc/ProductCatalogDataSourceB

#
# The name of the data source that should be used on startup
#
initialDataSourceName=DataSourceA

repository=/atg/dynamo/service/jdbc/SDSRepository


initialDataSourceName:


The short name for the DataSource that should be used for the currentDataSource on the very first run. On subsequent runs, the initial currentDataSource is obtained from the state recorded in the SDSRepository.


dataSources:


Set to a ServiceMap of DataSources. This property maps short names of DataSources to their Nucleus component path. The following example shows how you might set the dataSources property:

dataSources=FirstDataSource=\
/atg/dynamo/service/jdbc/FirstDataSource,\
  SecondDataSource=\
/atg/dynamo/service/jdbc/SecondDataSource


repository:


Set with a reference to /atg/dynamo/service/jdbc/SDSRepository


Database Switching and Query Caching


If you are using a GSA repository and set the cacheSwitchLoadQueries property of the GSAItemDescriptor to true, the query cache is loaded for a cache switch. If false, the query cache starts out empty after a cache switch.


Database Switching and Repository Caches


If you set the cacheSwitchHot property of the repository component to true, when the repository receives a SwitchingDataSourceEvent of type PREPARE from the SwitchingDataSource, it prepopulates off-line caches with data from the next DataSource. Then, when the switch occurs and the repository receives a SwitchingDataSourceEvent of type SWITCH from the SwitchingDataSource, the caches are not flushed; instead, the off-line caches go live. This can improve performance during and immediately after a database switchover.


Friday, November 22, 2013

Droplets and Form Handlers for Approving Orders : ATG

Droplets and Form Handlers for Approving Orders


When an order has been determined to require approval, and its order state has been set to PENDING_APPROVAL, an approver must then review the order and approve or reject it. ApprovalRequiredDroplet and ApprovalFormHandler are provided for this purpose.

Additionally, an approver might want to view a historical list of the orders he or she has approved and/or rejected. ApprovedDroplet is provided for this purpose.

ApprovalRequiredDroplet:


Use the ApprovalRequiredDroplet servlet bean to retrieve all orders requiring approval by a given approver. ApprovalRequiredDroplet queries the order repository and returns all orders that meet the following two criteria:

1. The order’s authorizedApproverIds property contains the approver’s ID.

2. he state of the order requires approval, meaning that the state is defined in the ApprovalRequiredDroplet orderStatesRequiringApproval property. The order’s state is held by the property of the order that is specified in the ApprovalRequireDroplet orderStatePropertyName property. The default value is PENDING_APPROVAL.

ApprovedDroplet:


Use the ApprovedDroplet servlet bean to retrieve all orders that have been approved and/or rejected by a given approver. ApprovedDroplet queries the order repository and returns all orders that have the approver’s profile ID in the approverIds property.

ApprovalFormHandler:


The ApprovalFormHandler form handler  processes an approver’s approval or rejection of an order. The ApprovalFormHandler class contains two handle methods, handleApproveOrder and handleRejectOrder.


You can associate these handle methods with Submit properties in the following manner:


<input type=submit bean="ApprovalFormHandler.approveOrder" value=" Approve Order">
<input type=submit bean="ApprovalFormHandler.rejectOrder" value=" Reject Order">


If the handleApproveOrder method is called for ApprovalFormHandler.approveOrder, the handleApproveOrder method executes the orderApproved pipeline chain. Similarly, if the handleRejectOrder method is called for ApprovalFormHandler.rejectOrder, the handleRejectOrder method executes the orderRejected pipeline chain.


Use JMS Messages in the Order Approval Process


ApprovalRequiredMessage :

JMS Type: atg.commerce.approval.ApprovalRequired

This message includes the order requiring approval and the profile repository item for the customer associated with the order as order and profile message properties, respectively. If you are using multisite, the siteId property is populated as well.

This message is sent to the /Approval/Scenarios JMS message topic, which allows the scenario server to interact with the message using SQL JMS and obtain the profile outside the current thread.


ApprovalMessage :

JMS Type: atg.commerce.approval.ApprovalUpdate

This message includes the order requiring approval and the profile repository item for the customer associated with the order as order and profile message properties, respectively. It also includes an approvalStatus message property.If you are using multisite, the siteId property is populated as well.

A message with a JMSType of either ApprovalUpdate or ApprovalComplete is sent to the /Approval/Scenarios JMS message topic, which allows the scenario server to interact with the message using SQL JMS and obtain the profile outside the current thread.

A message with a JMSType of ApprovalUpdate is also sent to the /Approval/ApprovalUpdate JMS message queue. ApprovalCompleteService listens for messages on this queue




Friday, October 18, 2013

Reset the Dyn/Admin Password in simple ways : ATG

Reset the Dyn/Admin Password:


Step 1 : Add the Admin.Reset to your Build ear, When adding this module to your build arguments, It will allow us to prompt to the Change password template

 









Step 2 :  And if you not sure what is your password . Use this below query and execute it in the query browser

update das_account set password = 'e64b78fc3bc91bcbc7dc232ba8ec59e0'
where account_name = 'admin';


your Password will be : Admin123

If you want to use some other MD5 hash words also

Different Admin password Are Given Below Along With MD5 Hash Words:

Admin1234  =  2da753c46e58b26de9a6c25acae32d6df6fde06adb8ef2cde66aad7436d235dd
admin =  21232f297a57a5a743894a0e4a801fc3




Thats it. so simple.



Popular Posts