Tuesday 25 December 2012


Access Bean 
    
     WCS commands interact with access beans rather than directly with the entity beans. Access beans behave like Java beans, & hide all enterprise bean-specific programming interfaces from the client.

Types of Access beans are:
  1. Copy Helper  methods.
  2. Finder methods.
  3. EJB methods.

There are 2 types of  Copy Helper methods:
  1. refreshCopyHelper()
  2. commitCopyHelper()

  • refreshCopyHelper():  refresh copy helper is treated as "find for update” and it locks that particular row unless or until you are done with entire transaction. So you read something with refreshcopyHelper and you keep doing n no of things and when you are finally done then only these locks are released.

          refreshCopyHelper reads the database to update the access bean.

  • commitCopyHelper():   commitCopyHelper() takes the current state of the access bean and updates the database with it.

         Updates the database with the contents of the access bean.  


Tuesday 11 December 2012

The Design patterns Present in WCS

Design patterns
The Design patterns Present in WCS:

  1. Model-View-Controller design pattern.
  2. Display design patterns.
  3. Command design patterns.
Model-View-Controller design pattern:

The model-view-controller (MVC) design pattern specifies that an application consist of a data model, presentation information, and control information.
The model (for example, the data information) contains only the pure application data; it contains no logic describing how to present the data to a user.
The view (for example, the presentation information) presents the model's data to the user. The view knows how to access the model's data, but it does not know what this data means or what the user can do to manipulate it.
Finally, the controller (for example, the control information) exists between the view and the model. It listens to events triggered by the view (or another external source) and executes the appropriate reaction to these events. In most cases, the reaction is to call a method on the model. Since the view and the model are connected through a notification mechanism, the result of this action is then automatically reflected in the view.




Command design pattern:

WebSphere Commerce Server accepts requests from browser-based thin-client applications; from applications such as the Sales Center; and remote applications. For example, a request may come from a remote procurement system, or from another commerce server.
  • Task command: These implement discrete pieces of a business task such as address verification or ensuring passwords comply to the defined password policies. For example, during executing of the Registration controller command a callout may be made to a task command to validate the address entered.
  • Controller command: These implement business tasks such as user registration and allocation of inventory. Use these to implement high-level process logic for the business task.
Display design pattern:

Display pages return a response to a client. Typically, display pages are implemented as JSP pages. In order to support multiple device types, a URL access to a page should use a view name, not the name of the actual JSP file.
The main rationale behind this level of indirection is that the JSP page represents a view. The ability to select the appropriate view (for example, based on locale, device type, or other data in the request context) is highly desirable, especially since a single request often has multiple possible views. Consider the example of two shoppers requesting the home page of a store, one shopper using a typical Web browser and the other using a cellular phone. Clearly, the same home page should not be displayed to each shopper. The Web controller's responsibility is to accept the request, then based upon information in the command registration framework, determine the view that each shopper receives.

Sunday 11 November 2012

Access Control Policies

          An Access Control Policies authorizes a group of users to perform a set of actions on a set of resources.

An access control policy has 4 elements, they are:
  1. User.
  2. Action.
  3. Resource.
  4. Relationship.

User:  The Users are the people that use the system. For access control purposes, users must be grouped into relevant access groups. 

Action: Actions are the activities that users can perform on the resource.

Resource: Resources are the entities that are protected. A resource group might include business objects like contract or order, or a set of related commands.

Relationship: Relationships are the relationship between the user and the resource. Access control policies may require that a relationship between the user and the resource be satisfied. Each resource class can have a set of relationships associated with it. Each resource can have a set of users that fulfill each relationship.


There are 2 types of access control policies, they are:

  1. Groupable standard policies(policy type-2).
  2. Groupable template policies(policy type-3).

     A Groupable standard policy is applied, once, at organizations that subscribe to a policy group that contains the policy.

     A Groupable template policies are dynamic in nature in that they have an access group that is scoped, when the system is running, to the organization that owns the resource.


The table updated in access control poliies are:

  1. ACACTION: Stores actions that are to be performed on the resources in the system.
  2. ACPOLICY: Stores all the access control policies in a system.
  3. ACRESGRP: Stores all access control resource groups in a system.
  4. ACPOLDESC: Stores local specific information for ACPOLICY.
  5. ACRELATION: Relation between resources and members in system.
  6. ACRESREL: Associates a resource and relationships that it supports.


        WebSphere Commerce allows you to determine, through access control, which tasks a particular user, be they customers, buyers, administrators, distributors, manufacturers, or suppliers, can perform in relation to your business.

To facilitate database management and ensure security, access to WebSphere Commerce must be restricted to specific individuals and organizations. The process of restricting access is referred to as access control or authorization. Authorization can be defined as security guidelines that:

Allow or deny a user of a system access to the resources managed by a system.
Specify what actions the user can perform on each resource.

The authorization model for WebSphere Commerce is based upon the enforcement of access control policies. Access control policies are enforced by the access control Policy Manager. In general, when a user attempts to access a protected resource, the access control policy manager first determines what access control policies are applicable for that user and then, based upon the applicable access control policies, it determines if the user is allowed to perform the requested operation on the given resource.

NOTE: The Site Administrator manages the access control policies that apply to a site or store.

Thursday 4 October 2012

Details about Data beans in WCS.


Data Bean :

A data bean is a Java bean that is used within a JSP page to provide dynamic content. A data bean normally provides a simple representation of a WebSphere Commerce entity bean. The data bean encapsulates properties that can be retrieved from or set within the entity bean. As such, the data bean simplifies the task of incorporating dynamic data into JSP pages.

A data bean is activated in one of the following ways:
  • by means of the wcbase:useBean tag (recommended)
  • by means of the following call:
com.ibm.commerce.beans.DataBeanManager.activate(data_bean, request, response)
where data_bean is the data bean to be activated, request is an HTTPServletRequest object, and response is an HTTPServletResponse object.

Types of data beans :

A data bean is a Java bean that is mainly used to provide dynamic data in JSP pages. There are two types of data beans:

  1.       Smart Data Bean.
  2.       Command Data Bean.
  • Smart data beans :
  • A smart data bean uses a lazy fetch method to retrieve its own data.
  • Smart data beans that require access to the database should extend from the access bean for the corresponding entity bean and implement the com.ibm.commerce.SmartDataBean interface.
  • For example, the OrderItemDataBean data bean extends the OrderItemAccessBean access bean, which corresponds to the OrderItem entity bean.
  • Some smart data beans do not require database access. At this case “When database access is not required, the smart data bean should extend the SmartDataBeanImpl class”. 
   Command data bean :
  • A command data bean relies on a command to retrieve its data and is a more lightweight data bean.
  • Command data beans can also extend from their corresponding access beans and implement the com.ibm.commerce.CommandDataBean interface.

Friday 7 September 2012

Tutorial Point offline browsing Link for download.

This Post is very much usefull to those who are not able to Browse the Internet for Java preparation Please download the material from this link

Please leave a comment and follow us for more updates and materials......

Prepare well all the best Friends.

Tuesday 4 September 2012

Steps in Publishing The .SAR file.

Publishing Steps for Store Archive (.sar)
· A store archive file (.sar) is a ZIP archive file that contains all the assets necessary to create a store or site. It is primarily used as a vehicle for packaging and delivering stores. You only need to publish a store archive to the WebSphere Commerce Server to create a functioning store or site that you can view, browse, and shop at.
· Store archive files are also used to package and deliver organization structures, predefined user roles, and access control policies necessary to create the environment for your store or site, as well as to package collections of assets used to create a catalog or storefront.
Publishing a Madisons.sar file: The steps are:
The sar file location is WCDE_installdir/starterstores/AddOnFeatures
· Open the Administration Console, selecting the Site option.
· From the Stores Archives menu, select Publish. The Store Archives page displays listing the store archives available for publish. By default, the page displaying composite store archives displays.
· From the View list, select Add On Feature.
· Select MadisonsEnhancements.sar.
· Click Next.
· Select the Madisons-based starter store onto which you want to publish the Madisons enhancements store archive. The Publish wizard must publish the Madisons enhancements store archive on top of the Madisons starter store; no other starter stores are supported. There are three stores:
1. Marketing Store.
2. Catalog Store.
3. Customer facing Store.
4. If you are using a single store setup then choose the same store for all three.
5. If you are using an Extended sites model, choose the appropriate stores that you are using.
· Click Next. The Summary page displays, listing the store archive and parameters selected, and the location to which the store archive is published.
· After reviewing the summary information, click Finish. A confirmation dialog displays, telling you the number of the publishing job. Note the job number for future reference.

· To check the publishing status, click Refresh.
· When the Publish Status column displays Successful, select the corresponding job number; then click Details.
· To launch the published store in a browser, click Launch Store.
· When you have finished viewing the store, bookmark the site, and close the browser.
· Restart the WebSphere Commerce Server.

Sunday 2 September 2012

Commands Present in Order Subsystem.

Some of the commands related to Order Sub-system are:
· com.ibm.commerce.order.commands.OrderDeleteCmd
· com.ibm.commerce.order.commands.OrderCancelCmd
· com.ibm.commerce.order.commands.OrderProfileUpdateCmd
· com.ibm.commerce.order.commands.OrderUnlockCmd
· com.ibm.commerce.order.commands.OrderScheduleCmd
· com.ibm.commerce.order.commands.ScheduledOrderCancelCmd
· com.ibm.commerce.order.commands.ScheduledOrderProcessCmd
· com.ibm.commerce.order.commands.OrderItemAddCmd
· com.ibm.commerce.order.commands.OrderItemDeleteCmd
· com.ibm.commerce.order.commands.OrderItemUpdateCmd
· com.ibm.commerce.order.commands.PayResetPMCmd
The tables in Order Sub-system are:
1. Orders
2. OrderMGP: Relation between Order & Member.
3. OrderItem
4. ORDITEMCONF: Relation between order items & order item shipment confirmation.
5. Ffmcenter
6. ORDUSERS: Contains information about users that worked with an order.
7. OrdTax: Represents the total tax for all order items in an order.
a. ORDSTAT: Contains information about the status of an Order Status Update inbound message.
b. ORDISTAT: This table contains information about the items within a single order for an Order Status Update inbound message.
8. SCHORDERS: Contains the entries for scheduled orders.
a. SUBORDERS: Contains subtotals of amounts for all the OrderItems of an Order with the same shipping address.
b. ORDPAYINFO: Holds a name-value pair representing payment information for a particular Order.
c. ORDPAYMTHD: The Order Payment Method table contains order payment or refund methods selected for an order.

Friday 31 August 2012

Details About Order SubSystem.

ORDER SUBSYSTEM
  • Order Sub-system is a component of WCS that provides shopping carts, order capture, order fulfillment, inventory & payment function support.
  • An order includes one or more products, billing & shipping addresses, payment details & the total cost including shipping charges & taxes.
  • From a customer persective an order is a list of selected products.
  • Each product in a list is called an order item.
  • From a store perspective an order is a list of order items.
  • Orders are associated with a single store.
  • An order profile is a special type of order that can be associated with either a store or a store group.
  • The order profile holds default information about a customer such as payment information, shipping address, shipping mode & billing address.
Ø There are 4 inventory systems, they are:
1. ATP inventory.
2. Non-ATP inventory.
3. No inventory.
4. External inventory.
ATP Inventory: The ATP inventory model enables you to allocate stock from existing inventory or backorder from expected inventory. You can also obtain an estimated availability time for each order item once it has been added into the shopping cart. The ATP also supports allocating stocks for future order processing.
Non-ATP Inventory: The non-ATP inventory model supports inventory operations that are only based on existing on-hand inventory.
No Inventory: The no inventory model assumes that all products have infinite quantities. When the products in a store are virtual products, digital downloadable products, or electronic assets, such as downloadable images or music.
External Inventory: External inventory is used for Websphere Commerce and some external inventory systems integration. For integration with other inventory systems, you might select ATP, non-ATP, or No-inventory inventory system based on the specific inventory system and integration scenario.
The shipping codes for an order sub-system are:
  • A - Payment Authorization requires review.
  • B - Backordered.
  • C - Payment Authorization complete.
  • D - Deposited.
  • E - CSR Edit.
  • F - Ready for remote fulfillment.
  • G - Pending remote fulfillment.
  • H - Error in remote fulfillment.
  • I - Submitted.
  • J - Trashcan.
  • L - No inventory.
  • M - Either a part or total amount is approved.
  • N - Approval denied.
  • P - Pending Order.
  • Q - Quick order profile.
  • R - Released.
  • S - Shipped.
  • T - Temparory.
  • W - Pending approval.
  • X - Cancelled.
  • Y - Private requisition list.
  • Z – Sharable requisition list.

Order Flow Process For Consumer Direct Store

Consumer Direct Order flow Process:


Place an order. A customer or an administrator who has the authority to act on behalf of the customer places an order with the store. Placing an order involves browsing the online catalog, selecting one or more products for the order, and providing billing, shipping, and offline payment information. Once the customer or administrator completes the order checkout, the order moves from P state (pending with products in the shopping cart) to M state (pending payment approval).
Approve payment for the order. Once the order has been placed, the next step is to approve payment for the order, using WebSphere Commerce Payments. Offline payments are automatically approved and the order moves from M state (pending payment approval) to C state (approved and ready to be released to fulfillment).
Release the order to fulfillment.
Create a pick batch for all orders released to the specified fulfillment center. Pick batches must be created for all fulfillment centers, including the channel store. Once you receive the products from the channel store, you can then pick and pack them for delivery to customers. All releases for the selected fulfillment center are placed in one batch; pick slips are created for each pick batch and packing slips are generated for the releases.
View and print pick ticket.
View and print packaging slip.
Pick and pack products specified in the pick ticket and packaging slip. Products specified in the pick ticket are then manually picked from the fulfillment center, and products are packed according to the instructions in the packing slips.
Create package.
Ship goods. Ship the order to the customer.
Confirm shipment has been sent.
Confirm Shipment. Once you have verified the shipment on the system, the status of the order changes to Shipped.
Note:
1. Pick Ticket: A printed document containing a list of all the products required to fulfill the releases in a given pick batch.
2. Pick Batch: A group of releases that are managed as a unit in a fulfillment center.
3. Fulfillment Center: Serves as a storage warehouse where products are packed & shipped to customers.

Thursday 30 August 2012

Commerce Exceptions

Class Summary
ECApplicationException
This class defines the exceptions thrown by the WebSphere Commerce Application Server when application errors occur during the processing of business logic.
ECException
This is an abstract base class used for defining exceptions thrown by the WebSphere Commerce Application Server.
ECParameterError
This class is a specialization of the service parameter error that uses an ECMessage to populate the error object.
ECSystemException
This class defines the exceptions thrown by the WebSphere Commerce Application Server when system errors occur during processing.
ExceptionHandler
This class contains methods & helper methods for converting Exception objects to ECException objects and generating ECException objects.
InvalidParameterValueException
This class defines the exception thrown by the WebSphere Commerce Application Server when a parameter error occurs.
ParameterNotFoundException
This class defines the exception thrown by the WebSphere Commerce Application Server when a parameter not provided by the client.

Wednesday 29 August 2012

Details about Access Control Policies.

An Access Control Policies authorizes a group of users to perform a set of actions on a set of resources.
An access control policy has 4 elements, they are:
1.User.
2.Action.
3.Resource.
4.Relationship.
User: The Users are the people that use the system. For access control purposes, users must be grouped into relevant access groups.
Action: Actions are the activities that users can perform on the resource.
Resource: Resources are the entities that are protected. A resource group might include business objects like contract or order, or a set of related commands.
Relationship: Relationships are the relationship between the user and the resource. Access control policies may require that a relationship between the user and the resource be satisfied. Each resource class can have a set of relationships associated with it. Each resource can have a set of users that fulfill each relationship.
There are 2 types of access control policies, they are:
1.Groupable standard policies(policy type-2).
2.Groupable template policies(policy type-3).
A groupable standard policy is applied, once, at organizations that subscribe to a policy group that contains the policy.
Groupable template policies are dynamic in nature in that they have an access group that is scoped, when the system is running, to the organization that owns the resource.
The table updated in access control poliies are:
1.ACACTION: Stores actions that are to be performed on the resources in the system.
2.ACPOLICY: Stores all the access control policies in a system.
3.ACRESGRP: Stores all access control resource groups in a system.
4.ACPOLDESC: Stores local specific information for ACPOLICY.
5.ACRELATION: Relation between resources and members in system.
6.ACRESREL: Associates a resource and relationships that it supports.
WebSphere Commerce allows you to determine, through access control, which tasks a particular user, be they customers, buyers, administrators, distributors, manufacturers, or suppliers, can perform in relation to your business.
To facilitate database management and ensure security, access to WebSphere Commerce must be restricted to specific individuals and organizations. The process of restricting access is referred to as access control or authorization. Authorization can be defined as security guidelines that:
  1. Allow or deny a user of a system access to the resources managed by a system.
  2. Specify what actions the user can perform on each resource.
The authorization model for WebSphere Commerce is based upon the enforcement of access control policies. Access control policies are enforced by the access control Policy Manager. In general, when a user attempts to access a protected resource, the access control policy manager first determines what access control policies are applicable for that user and then, based upon the applicable access control policies, it determines if the user is allowed to perform the requested operation on the given resource.
The Site Administrator manages the access control policies that apply to a site or store.

Tuesday 28 August 2012

Details about Beans Present in WCS..

A data bean is a java bean that is used within a jsp page to provide dynamic contect to the jsp page. A data bean normally provides a simple representaion of a WebSphere Commerce Entity bean.
There are 3 types of data beans:
1.Smart databean.
2.Command databean
3. Input data bean

  • Smart data bean: When a smart data bean is activated, the data bean manager invokes the data bean's populate method. Using the populate method, the data bean can retrieve all attributes, except attributes from associated objects.
  • Command data bean: A data bean implementing the CommandDataBean interface retrieves data from a data bean command. A data bean of this type is a lightweight object; it relies on a data bean command to populate its data. The data bean must implement the getCommandInterfaceName() method which returns the interface name of the data bean command.
  • Input data bean: A data bean implementing the InputDataBean interface retrieves data from the URL parameters or attributes set by the view.
Attributes defined in this interface can be used as primary key fields to fetch additional data. When a JSP page is invoked, the generated JSP servlet code populates all the attributes that match the URL parameters, and then activates the data bean by passing the data bean to the data bean manager. The data bean manager then invokes the data bean's setRequestProperties() method (as defined by the com.ibm.commerce.InputDataBean interface) to pass all the attributes set by the view.
Access Bean
WCS commands interact with access beans rather than directly with the entity beans. Access beans behave like Java beans, & hide all enterprize bean-specific programming interfaces from the client.
Types of Access beans are:
1. Copy Helper methods.
2. Finder methods.
3. EJB methods.
There are 2 types of Copy Helper methods:
1. refreshCopyHelper()
2. commitCopyHelper()
refreshCopyHelper(): refresh copy helper is treated as "find for update” and it locks that particular row unless or until you are done with entire transaction. So you read something with refreshcopyHelper and you keep doing n no of things and when you are finally done then only these locks are released.
refreshCopyHelper reads the database to update the access bean.
commitCopyHelper(): commitCopyHelper() takes the current state of the access bean and updates the database with it.
Updates the database with the contents of the access bean.

Entity Bean: The persistence layer within the WebSphere Commerce architecture is implemented according to the EJB component architecture.
A small number of stateless session beans are used to handle intensive database operations, such as performing a sum of all the rows in a particular column. One advantage of using entity beans is that developers can utilize the EJB tools provided in WebSphere Commerce Developer. These tools allow developers to define Java objects and their database table mappings. The tools automatically generate the required persisters for the entity beans. Persisters are Java objects that persist Java fields to the database and populate Java fields with data from the database.

Solr settings and full indexing (Attribute task update)

SOLR is mainly used for : Indexing Querying    SOLR is a product of apache and having the inbuilt server named jeety. Mainly the ...