Configuring the Quick Publish scheduler to run a job on an instance or cluster member

Procedure

Step-1

1. Log onto the WebSphere Administrative Console.
2. Select Servers > Application Servers.
3. Select your WebSphere Commerce Server name. For example, server1.
4. On the Application Servers panel, under the Server Infrastructure heading, select Java and Process Management > Process Definition.
5. On the Process Definition panel, under the Additional Properties heading, select Java Virtual Machine.
6. In the middle window, on the right hand side under the Additional Properties heading, select Custom Properties.
7. Click New. A new page opens for you to add additional JVM properties.
8. In the Name field, enter com.ibm.commerce.scheduler.SchedulerHostName.
9. In the Value field, enter the unique identifier of the scheduler instance on this Java process.
10. In the Description field, enter the host name parameter for this scheduler instance to use.

Step-2

Update the value of the quick publish JVM name attribute in the wc-resource-containers.xml file.
a.Open the WC_profiledir\installedApps\cell_name\WCServer_enterprise_archive\xml\content-management\wc-resource-containers.xml file for editing.
b.Locate the <wc:QuickPublishConfiguration> element, and add the jvmName parameter as shown:
<wc:QuickPublishConfiguration>
<wc:Publisher className="com.ibm.commerce.context.content.resources.publish.De
faultJDBCContentPublisherImpl"  initParameters=[other-parameters]
jvmName="QPHostname" [other-parameters]/ >
</wc:QuickPublishConfiguration>

How to disable workspaces, if needed after enabled

Workspace can't be disabled after they are enabled during instance creation. workspace is created, we can't remove database schema associated with workspace. however, we can prevent business users from using workspaces by preventing workspaces from displaying in the MC.

modify the instance file as follows:

WC_installdir/instances/<instance_name>/xml/instance.xml

1. search for WorkspaceTaskList and set the enabled parameteer to false.

after makeing this change, the line look like this:

<component enabled="false" name="WorkspaceTaskList"/>

this setting for workspaceTaskList component disables the workspace function within the tools:

2. After changes are complete, run theUpdateEar ant task to reflect the change on the app server.

Setting webcontainer custom properties in WAS

1. In the administrative console, click "Servers" and under Servers click "Server Types" and under Server Types click "WebSphere application servers"
2. Click on the server to which the custom property is to be applied
3. Under "Configuration" and "Container settings" click "Web Container Settings" and under Web Container Settings click "Web container"
4. Under "Configuration" and "Additional Properties" click "Custom Properties"
5. In the Custom Properties page, click "New"
6. In the settings page, enter the name of the custom property to be added in the "Name" field and the value to be set for the custom property in the "Value" field. Note that some properties are case sensitive.
7. Click "Apply" or "OK"
8. Click "Save" in the "Messages" box that appears
9. Restart the server for the custom property to take effect

Forgot password and cannot access WAS administrative console

There are 2 possible methods for disabling security

By way of wsadmin command: Server must be stoped

Method : 1

1. <WAS_INSTALL_DIR>/bin/> wsadmin -conntype NONE
2. wsadmin> securityoff
3. wsadmin> exit
4. Restart the servers.
5. Enable the security from administrative console.
6. Restart the servers.
Method : 2

By way of manual edit of security.xml file: /opt/IBM/WebSphere/AppServer/profiles/profile_name/config/cells/cell/security.xml

1. Create a copy for security.xml file, in case you need to roll back.
2. Disable the security from the security.xml file (change the very first occurrence of... enabled="true" to enabled="false")
3. Restart the servers.
4. Enable the security from administrative console.
5. Restart the servers.

How to find enabled WebSphere Commerce features

You can list the features that have been enabled on WebSphere Commerce.

1. Navigate to the following directory
    
    WCSDIR/bin

2. Run the check enablement status script
    
   checkEnablementStatus.bat


3. Confirm the feature enablement status from the following location.

   WCSDIR/logs\enableFeature.log



Sample Screen

How WCS selects the correct price from OFFER table?

Offers for catalog entries are stored in the OFFER table. When setting pricing for catalog entries, WC uses specific criteria to find valid offers from the OFFER table and then select the correct price.

To set the price for a catalog entry, WC must first determine all the valid offers for each applicable price list. To be valid, the offer must meet the following criteria according to data in the OFFER table: 

1. The offer must be published, that is, the PUBLISHED value must be 1.
2. The quantity of the catalog entry being purchased must be within the MINIMUMQUANTITY and MAXIMUMQUANTITY values for the offer.
3. The purchase date must be within the defined STARDATE and ENDDATE values for the offer.

If you load pricing data into WC using the data loader utility or SQL statements, it is possible to have more than one valid offer for a catalog entry. If there is more than one valid offer, WC sets the price using the offer with the highest value in the PRECEDENCE column of the OFFER table. If multiple offers exist with that same highest precedence value, the offer with the lowest price is used.

Price rules and offer price selection

If your store uses price rules for storefront pricing, the price rule also retrieves offers from the OFFER table, but then the price rule might perform additional calculations on the offer price.

In this price rule, the Get Price from Price List action retrieves the offer from the OFFER table and then performs the mark down and rounding on the offer price. To evaluate and select the correct offer to retrieve from the OFFER table, WC uses the same criteria described earlier in this topic.

Solr concept and Architecture

Conceptually, the Solr can be divided into four blocks:

    Mode (schema.xml)
    Configuration (the solrconfig.xml)
    Index
    Search

A Document contains one or more Field, A Field by name, content, and content approach of metadata. Analysis of the content to be searched. Analysis is completed by a Tokenizer and zero or more TokenFilter link to the Tokenizer to the input stream split into words (tags) TokenFilter can change (for example, stem) or remove the tag . Solr schema can easily configure the code analysis process. It also provides a more powerful type of feature that allows you to Field specific designated as String, int, float, or other type of original or custom.

Solr schema for the index is defined in schema.xml. it contains field type definitions within  the <types> element and the index's fields within <fields> elements. you may also notice <copyField> element, which copy an input field as provided to another field.

1. Schema design decisions in which you map your source data to document limited structure.
2. The structure of the schema.XML file where the schema definition is defined. Within this file are both the definition of field types and the fields of those types that store your data.
3. Text analysis—the configuration of how text is processed (tokenized and so on) for indexing. This configuration affects whether or not a particular search is going to match a particular document.

In the configuration, the solrconfig.xml file specified not only Solr how to deal with the index, highlight, classify, search, and other requests, and also specifies the properties used to specify the cache approach, and used to specify the method of the Lucene index properties . Configuration depends on the model, but the pattern does not depend on the configuration.

Solr's solrconfig.xml file contains lots of parameters that can be tweaked. At the moment, we're just going to take a peak at the request handlers, which are defined with <requestHandler> elements. They make up about half of the file. In our first query, we didn't specify any request handler.

<requestHandler name="search" class="solr.SearchHandler default="true">
<!-- default values for query parameters can be specified, these will be overridden by parameters in the request -->
   <lst name="defaults">
   <str name="echoParams">explicit</str>
   <int name="rows">10</int>
   </lst>
</requestHandler>

Each HTTP request to Solr, including posting documents and searches, goes through a particular request handler. Handlers can be registered against certain URL paths by naming them with a leading "/".

<requestHandler name="/update" class="solr.XmlUpdateRequestHandler" />