Friday, October 3, 2014

ATG integration with Weblogic publishing ear in admin console

The first step is to build ear using ant build xml file. The ear file contains many project which will be bundled under single ear to deploy on weblogic server. To deploy on weblogic the following steps should be followed:

1) Create DB connection setup in weblogic admin console for PROD_CATA, PROD_CATB & PROD_CORE
2) Create App server
3) Attach DB targets for the app server where ear has to be deployed
4) Deploy the ear in admin console
5) start server

Many app server can be created and multiple ear can be deployed on each server on different ports like publishing server, production server & POC server etc...

ATG ACC setup for updating catalog

Build BCC ear using ant build xml file. The ear file should be deployed on publishing server in admin console for BCC setup.

ACC can be used on production schema for development purpose.
To open GUI, invoke "startACC.bat" from c:\ATG\ATG11.0\home\bin

Enter credential admin/admin and connect to production server.
It has various option for updating/creating new data for catalog Management, category hierarchy, product/sku creation/update, Targeters, Scenarios, content etc...
New repository can also be added to update via ACC by updating file: atg/registry/ContentRepositories

ACC can be used even for pipeline design, browsing all jsp under war deployed on app servers.
Mostly used to update category hierarchy, data population for item descriptors defined either in customCatalog.xml or any repository xml file.


ATG Inventory Manager basics

InventoryManager Implementations
Oracle ATG Web Commerce includes the following implementations of the InventoryManager out of the box.

  1.     AbstractInventoryManagerImpl
  2.     NoInventoryManager
  3.     RepositoryInventoryManager
  4.     CachingInventoryManager
  5.     LocalizingInventoryManager
  6.     RepositoryInventoryManager

RepositoryInventoryManager
 This is a repository based implementation of InventoryManager. It implements all the methods defined by the InventoryManager API. It is a thin wrapper around a repository that contains the inventory information. This allows a maximum amount of flexibility for potential third party integrators. Integrators can simply implement a repository containing the required properties for cooperation with the RepositoryInventoryManager. The Repository InventoryManager can then be configured to extract inventory manager information from the third party repository.

This class also is a message source. It can send UpdateInventory messages if there is new inventory available for a previously unavailable item.

StoreInventoryManager
This class is an extension of the RepositoryInventoryManager. It will be responsible for writing to the inventory repository. This should only happen from the fulfillment server.

Caching the Inventory
      By default, caching is turned off for the inventory repository. This is to insure that inventory data is always up to date across server instances. The CachingInventoryManager is provided as an effective inventory caching mechanism for displaying inventory information.
      
      The CachingInventoryManager can be used to display information to customers as they browse the product catalog because, in most situations, inventory information displayed to customers during catalog browsing does not need to be updated in real time. Displaying inventory information using the CachingInventoryManager improves the performance of the site.
      
      The CachingInventoryManager should not be used when real time inventory data is needed. Real time inventory information is usually needed during the purchase process and fulfillment process. In those cases, the (uncached) InventoryManager should be used during these processes. For more information on the CachingInventoryManager, see the InventoryManager Implementations section.
      
      The InventoryDroplet provides cached data to the user when appropriate and accesses real time inventory data from the repository when appropriate. The useCache property allows you to indicate when to use cached inventory data:
      
          If the useCache property is set to false, the inventory data in the repository is provided.
      
          If the useCache property is set to true, the cached data is provided.
      
The GSA can provide more complex types of caching. If appropriate, you can configure two instances of the InventoryRepository GSA, one with no caching and one with distributed caching (set cache-mode=distributed). You can configure one instance of the RepositoryInventoryManager to use the uncached GSA, and another instance of the RepositoryInventoryManager to use the cached GSA. For more information on distributed caching, see the SQL Repository Caching chapter in the ATG Repository Guide.


ATG Commerce Schema

The ATG Commerce database schema includes the following types of tables:
  1.     Product Catalog Tables
  2.     Commerce Users Tables
  3.     Claimable Tables
  4.     Shopping Cart Events Table
  5.     Inventory Tables
  6.     Order Tables
  7.     Promotion Tables
  8.     User Promotion Tables
  9.     Gift List Tables
  10.     Price List Tables
  11.     Custom Catalog Tables
  12.     Abandoned Order Services Tables
  13.     Order Markers Table


    Product Catalog Tables:  ATG Commerce uses the following tables to store product catalog information:
  1.         dcs_folder
  2.         dcs_media
  3.         dcs_media_ext
  4.         dcs_media_bin
  5.         dcs_media_txt
  6.         dcs_category
  7.         dcs_product
  8.         dcs_product_acl
  9.         dcs_sku
  10.         dcs_cat_groups
  11.         dcs_cat_chldprd
  12.         dcs_cat_chldcat
  13.         dcs_cat_ancestors
  14.         dcs_cat_rltdcat
  15.         dcs_cat_keywrds
  16.         dcs_cat_media
  17.         dcs_cat_aux_media
  18.         dcs_prd_keywrds
  19.         dcs_prd_media
  20.         dcs_prd_aux_media
  21.         dcs_prd_chldsku
  22.         dcs_prd_skuattr
  23.         dcs_prd_groups
  24.         dcs_prd_rltdprd
  25.         dcs_prd_ancestors
  26.         dcs_sku_attr
  27.         dcs_sku_link
  28.         dcs_sku_bndllnk
  29.         dcs_sku_media
  30.         dcs_sku_aux_media
  31.         dcs_sku_replace
  32.         dcs_sku_conf
  33.         dcs_config_prop
  34.         dcs_conf_options
  35.         dcs_config_opt
  36.      dcs_foreign_cat


Commerce Users Tables:  ATG Commerce uses the following tables to store information about commerce users:
  1.     dps_credit_card
  2.     dcs_user
  3.     dps_usr_creditcard


Claimable Tables:  ATG Commerce uses the following table to store claimable information:
  1.     dcspp_claimable
  2.     dcspp_giftcert
  3.     dcs_storecred_clm
  4.     dcspp_coupon


Shopping Cart Events Table:   ATG Commerce uses the following table to store information about shopping cart events:

  1. dcs_cart_event
Inventory Tables:  ATG Commerce uses the following tables to store inventory information:

  1. dcs_inventory

Order Tables:   ATG Commerce uses the following tables to store order information:

  1.     dcspp_order
  2.     dcspp_ship_group
  3.     dcspp_pay_group
  4.     dcspp_item
  5.     dcspp_relationship
  6.     dcspp_rel_orders
  7.     dcspp_order_inst
  8.     dcspp_order_sg
  9.     dcspp_order_pg
  10.     dcspp_order_item
  11.     dcspp_order_rel
  12.     dbcpp_sched_order
  13.     dcspp_ship_inst
  14.     dcspp_hrd_ship_grp
  15.     dcspp_ele_ship_grp
  16.     dcspp_ship_addr
  17.     dcspp_hand_inst
  18.     dcspp_gift_inst
  19.     dcspp_sg_hand_inst
  20.     dcspp_pay_inst
  21.     dcspp_config_item
  22.     dcspp_subsku_item
  23.     dcspp_item_ci
  24.     dcspp_gift_cert
  25.     dcspp_store_cred
  26.     dcspp_credit_card
  27.     dcspp_bill_addr
  28.     dcspp_pay_status
  29.     dcspp_cc_status
  30.     dcspp_gc_status
  31.     dcspp_auth_status
  32.     dcspp_debit_status
  33.     dcspp_cred_status
  34.     dcspp_shipitem_rel
  35.     dcspp_rel_range
  36.     dcspp_det_range
  37.     dcspp_payitem_rel
  38.     dcspp_payship_rel
  39.     dcspp_payorder_rel
  40.     dcspp_amount_info
  41.     dcspp_order_price
  42.     dcspp_item_price
  43.     dcspp_tax_price
  44.     dcspp_ship_price
  45.     dcspp_amtinfo_adj
  46.     dcspp_price_adjust
  47.     dcspp_itmprice_det
  48.     dcspp_det_price
  49.     dcs_submt_ord_evt
  50.     dcs_ord_merge_evt
  51.     dcspp_order_adj
  52.     dcspp_manual_adj


Promotion Tables:  ATG Commerce uses the following tables to store information about promotions:

  1.     dcs_promotion
  2.     dcs_promo_media
  3.     dcs_discount_promo
  4.     dcs_promo_upsell
  5.     dcs_upsell_action
  6.     dcs_close_qualif
  7.     dcs_prm_cls_qlf
  8.     dcs_upsell_prods
  9.     dcs_prom_used_evt
  10.     dcs_promo_rvkd
  11.     dcs_promo_grntd


User Promotion Tables:  ATG Commerce uses the following tables to store information about user promotions:

  1.     dcs_usr_promostat
  2.     dcs_usr_actvpromo
  3.     dcs_usr_usedpromo


Gift List Tables:  ATG Commerce uses the following tables to store information about gift lists and wish lists:

  1.     dcs_giftlist
  2.     dcs_giftinst
  3.     dcs_giftitem
  4.     dcs_giftlist_item
  5.     dcs_user_wishlist
  6.     dcs_user_giftlist
  7.     dcs_user_otherlist


Price List Tables:  The following database tables store information related to price lists.

  1.     dcs_price_list
  2.     dcs_complex_price
  3.     dcs_price
  4.     dcs_price_levels
  5.     dcs_price_level
  6.     dcs_gen_fol_pl
  7.     dcs_child_fol_pl
  8.     dcs_plfol_chld


Custom Catalog Tables:  The following database tables store information related to the custom catalogs.

  1.     dcs_catalog
  2.     dcs_root_cats
  3.     dcs_allroot_cats
  4.     dcs_root_subcats
  5.     dcs_sub_catalogs
  6.     dcs_category_info
  7.     dcs_product_info
  8.     dcs_sku_info
  9.     dcs_cat_subcats
  10.     dcs_cat_subroots
  11.     dcs_cat_catinfo
  12.     dcs_catinfo_anc
  13.     dcs_prd_prdinfo
  14.     dcs_prdinfo_rdprd
  15.     dcs_prdinfo_anc
  16.     dcs_sku_skuinfo
  17.     dcs_skuinfo_rplc
  18.     dcs_gen_fol_cat
  19.     dcs_child_fol_cat
  20.     dcs_catfol_chld
  21.     dcs_dir_anc_ctlgs
  22.     dcs_ind_anc_ctlgs
  23.     dcs_ctlg_anc_cats
  24.     dcs_cat_prnt_ctlg
  25.     dcs_cat_anc_cats
  26.     dcs_prd_prnt_cats
  27.     dcs_prd_anc_cats
  28.     dcs_cat_catalogs
  29.     dcs_prd_catalogs
  30.     dcs_sku_catalogs
  31.     dcs_user_catalog


Abandoned Order Services Tables:  ATG Commerce uses the following tables to store information about users’ abandoned orders:

  1.     dcspp_ord_abandon
  2.     dcs_user_abandoned
  3.     drpt_conv_order
  4.     drpt_session_ord


Order Markers Table:  The following section describes the table used to hold order marker information.
  1. dcs_order_marker

ATG Commerce with Custom Catalogs

Custom Catalogs allow you to set up your product catalog so different customers see different information about the products they view, or different products altogether.

ATG Commerce run in two separate modes:

development mode: Uses derived properties so that you can preview a product catalog on a web site while you’re making changes without having to run the batch service (CatalogMaintenanceService). Development mode makes the updates incrementally so you can preview your changes throughout the development process.
Development mode overrides the definitions of certain properties in the catalog repository that are normally computed by the batch service, and these properties are derived on-the-fly. Development mode is more resource intensive than production mode because these properties have to be computed at the time they are referenced, rather than being pre-computed by the batch service.

The development mode allows you to preview the custom catalogs as you edit them.

production mode: Uses computed properties. This mode uses the properties pre-computed by the batch service, so performance is upgraded over development mode because time is no longer spent deriving the property values.

The production mode is the most efficient mode to run in when you won’t need to preview changes to the custom catalog.

ATG Catalog Maintenance System (CMS)

ATG catalogs use several batch and dynamic services to perform catalog updates and to verify catalog relationships. These services are collectively referred to as the Catalog Maintenance System (CMS). The CMS updates property values that enable navigation and hierarchical search. It also verifies the relationships of catalog repository items and properties.

Batch Services
There are four services that facilitate the updating of the catalog in batch mode. All batch services can be run on demand or in scheduled mode. They are:

  1. AncestorGeneratorService
  2. CatalogVerificationService
  3. CatalogUpdateService
  4. CatalogMaintenanceService


Dynamic Services
Dynamic Services consists of components that enable the catalog properties to be dynamically updated as the catalog structure is modified by an ACC user, BCC user, or a program using the Repository API.

  1. CatalogChangesListener
  2. CatalogCompletionService
  3. StandardCatalogCompletionService

ATG Pipeline Manager

The Pipeline Manager controls a series of processors, which make up a processor chain. Each processor in the processor chain is a component that performs a specific function and returns a status code. The status code can determine which processor to execute next.

The PipelineManager Nucleus component for ATG Commerce is located at /atg/commerce/PipelineManager. In ATG Consumer Commerce, the related XML configuration file is defined in <ATG9dir>/B2CCommerce/config/atg/commerce/commercepipeline.xml.

The following pipeline chains are defined in commercepipeline.xml.
  1. updateOrder Pipeline Chain: Saves the order supplied to it.
  2. loadOrder Pipeline Chain: Loads the order from the repository whose ID is supplied as a parameter.
  3. refreshOrder Pipeline Chain: Reloads an order after an error and causes the unloaded portion of an Order to be loaded when accessed.
  4. processOrder Pipeline Chain: Submits the given order for checkout.
  5. validateForCheckout Pipeline Chain: Verifies that the order is ready for checkout.
  6. validatePostApproval Pipeline Chain: Revalidates an order after approval.
  7. validatePaymentGroupsPostApproval Pipeline Chain: Validates each payment group in an order after the order has been approved.
  8. validateNoApproval Pipeline Chain: Validates an order that does not require approval.
  9. recalcPaymentGroupAmounts Pipeline Chain: Regenerates the amount that must be assigned to each PaymentGroup in the order.
  10. repriceOrder Pipeline Chain: Prices the order
  11. moveToConfirmation Pipeline Chain: Prices the order and validates it.
  12. moveToPurchaseInfo Pipeline Chain: Validates the order.
  13. validateShippingInfo Pipeline Chain: Validates the shipping groups in the order.
  14. sendScenarioEvent Pipeline Chain: Sends a message to the Dynamo Message System
/atg/commerce/invoice/pipeline/InvoicePipelineManager
/atg/commerce/payment/PaymentPipelineManager
/atg/commerce/PipelineManager


/atg/commerce/PipelineManager/

$class=atg.commerce.pipeline.CommercePipelineManager

# The location of the XML configuration file in the classpath.
# Default: /atg/commerce/CommercePipeline.xml
definitionFile=/atg/commerce/commercepipeline.xml


# The transaction manager that the PipelineManager will use to coordinate its
# transactions.
transactionManager=/atg/dynamo/transaction/TransactionManager

Steps to create pipeline:
1) update commercepipeline.xml
<pipelinechain name="moveToConfirmation" transaction="TX_REQUIRED" headlink="executeMyCustomChain" xml-combine="append">
      <pipelinelink name="executeMyCustomChain2" transaction="TX_MANDATORY">
         <processor jndi="/atg/commerce/order/processor/ExecuteValidateForCheckoutChain"/>
        <transition returnvalue="1" link="executeMyCustomChain3"/>
      </pipelinelink>
       <pipelinelink name="executeMyCustomChain3" transaction="TX_MANDATORY">
               <processor jndi="/com/test/processor/ProcessMyPipeline"/>
       </pipelinelink>     
       </pipelinechain>
2) CustomPipeline.properties
pipelineManager=/atg/commerce/PipelineManager
moveToConfirmationPipelineProcess=moveToConfirmation 
3) public class CustomPipelineFormHandler extends PaymentGroupFormHandler {
........................
public void runProcessMoveToConfirmation(DynamoHttpServletRequest pRequest,
            DynamoHttpServletResponse pResponse) {
            ............
PipelineResult result =  runProcess(moveToConfirmationPipelineProcess(), ....);
            processPipelineErrors(result);


Adding a Commerce Processor Using XML Combination

There are two ways to extend a pipeline defined for a PipelineManager. One is to copy the entire XML file into your CONFIG layer and make the necessary changes. The other way is to use XML combination. Using XML combination is the preferred approach. The example below demonstrates of how to use XML combination to modify a pipeline chain.

The XML below is a section of the processOrder pipeline chain as it appears out of the box.

<pipelinechain name="processOrder" transaction="TX_REQUIRED"
           headlink="executeValidateForCheckoutChain">
  <pipelinelink name="executeValidateForCheckoutChain" transaction="TX_MANDATORY">
     <processor
            jndi="/atg/commerce/order/processor/ExecuteValidateForCheckoutChain"/>
     <transition returnvalue="1" link="checkForExpiredPromotions"/>
  </pipelinelink>
  <pipelinelink name="checkForExpiredPromotions" transaction="TX_MANDATORY">
     <processor jndi="/atg/commerce/order/processor/CheckForExpiredPromotions"/>
     <transition returnvalue="1" link="removeEmptyShippingGroups"/>
</pipelinelink>

The following example demonstrates how to add a new processor called purgeExcessOrderData between the executeValidateForCheckoutChain and checkForExpiredPromotions processors in the processOrder pipeline chain. The following XML code should be added to your config layer.

The important sections of this code are the additions of the xml-combine attributes in the pipelinechain and pipelinelink tags. The pipelinechain tag indicates what is being appended to its contents. The pipelinelink tag for executeValidateForCheckoutChain indicates what is replacing its contents.

<pipelinemanager>
 <pipelinechain name="processOrder" transaction="TX_REQUIRED"
            headlink="executeValidateForCheckoutChain" xml-combine="append">
   <pipelinelink name="executeValidateForCheckoutChain" transaction="TX_MANDATORY"
         xml-combine="replace">
     <processor
           jndi="/atg/commerce/order/processor/ExecuteValidateForCheckoutChain"/>
     <transition returnvalue="1" link="purgeExcessOrderData"/>
   </pipelinelink>
   <pipelinelink name="purgeExcessOrderData" transaction="TX_MANDATORY">
     <processor jndi="/atg/commerce/order/processor/PurgeExcessOrderData"/>
     <transition returnvalue="1" link="checkForExpiredPromotions"/>
   </pipelinelink>
 </pipelinechain>
</pipelinemanager>

The purgeExcessOrderData processor’s transition is what the executeValidateForCheckoutChain's transition is in the base file within the commerce platform.