Posts

Showing posts from 2014

REST WebServices in ATG Using Jersey

REST Services in ATG Using Jersey This blog describes how ATG components can be exposed as RESTful web services using a JAX-RS implementation like Jersey. It is intended to give a step-by-step walkthrough on setting up Rest services in ATG application.  Limitations of ATG restfull webservices. Some of them are: 1.  Fixed URI pattern – ATG REST services slot all services into Repository and bean category and contain the component path details. This limits the flexibility to design meaningful URIs. 3.  All parameters passed to ATG REST service components are passed as...

Best practices to connect thirdparty services from ATG

This issue typically occurs when ATG uses a client to access external hosted services over http when the read/connection timeout are not configured.The speed and integrity of the external services is outside of the control of ATG however if these services are unavailable any attempt to connect to them over http will result in a connection (or thread) which does not timeout (the default http connection timeout is configured to -1 or 0 which is infinite). This results in a build of hanging threads in the ATG application which wait on the default http timeout. . Recommendations Below is a list of recommendations to overcome outages 1.     Prevent client requests invoking application threads indefinitely . Set the  sun.net.client.defaultConnectTimeout  and  sun.net.client.defaultReadTimeout 2.     Prevent application from using an thirdparty services which are unavailable . Implement a mechanism for preventing unnece...

JMS publish/subscribe pattern in ATG

The basic JMS publish/subscribe pattern leads to create an infinite number of same message executions. The issue basically occurs when the  MessageConsumer is not able to successfully process the message.  When it occurs the transaction is rolled back and the message is put  back on the queue.   The  Subscriber  try to retries to process the message ,when  this message has been put back in the Message Queue . The message will be successfully processed,if the error is result of a temporary condition. However, it is possible to create an infinite loop message executions, if the issue is as a result of invalid message.  This will eventually leads to overwhelms the database with the large number of updates and rollbacks. Recommendations: 1.       Use SQL JMS messages for all business critical operations .example: order or a customer profile updates. 2.       Limit the number of JMS message retries 3. ...