Activating users using a script

This is usually a problem with a lot of sites where due to a security password policy, users are deactivated after a certain number of unsuccessful attempts in trying to log in. It could be frustrating for support folks to manually activate the users.

A cron job can be created with a script to activate users deactivated in the last day. There is 2 things required one to run the script below and second to refresh the customer profile cache registry.

Step1:

update userreg
set status=1,passwordinvalid=null
where trunc(passwordinvalid) >= sysdate-1 and status=0;

Step2:
Refresh Customer profile Cache Registry

Installing RAD SQL Profiler in WebSphere Commerce Developer 7

The IBM SQL profiler is a great tool to find database related performance problems.
However, the current guide only covers how to install it on WCS 6.

Here is an updated list of steps for those of you that need to install it in WCS developer 7.

Dynacache Tip: Dynamically skip cache for a page

The usual way most people diagnose DynaCache problems is by commenting out or removing the cache-entry or cache-id snippet in cachespec.xml. Since cachespec.xml changes are loaded without restarting, this works pretty well.

While this works fine, sometimes I want to be able to see what the page looks like without caching quickly, without having to edit cachespec.xml. Sometimes the changes to cachespec.xml would require creating a support ticket to modify a QA or DEV environment.

A more dynamic solution is to use a servlet filter to disable caching for a top level page without touching DynaCache.

Here is code for such a servlet filter:


This filter will disable caching when the URL contains the parameter "nocache" with value "true".
Example: http://localhost/webapp/wcs/stores/servlet/StoreCatalogDisplay?langId=-1&storeId=10151&catalogId=10551&nocache=true

Keep in mind that this only disables caching for the URL you are hitting in your browser and does not affect caching of child fragments which are not consumed by that URL.

This filter should only be used in DEV or QA environments.

Dynacache Tip: Exclude JSP fragment from cache

Scenario:

1. You are caching a JSP in cachespec.xml, lets call it "parent.jsp".

2. You have configured "parent.jsp" to consume sub-fragments.

3. There is a JSP being included by parent.jsp, lets call it "child.jsp"

4. The file is being included using the <c:import> tag

5. You don't want to cache child.jsp at all
6. You don't want parent.jsp to consume child.jsp into its cache

Solution:

Add the following line in child.jsp:

<% ((com.ibm.websphere.servlet.cache.ServletCacheResponse)response).setDoNotConsume(true); %>

This way gets around having to add child.jsp to cachespec.xml and setting do-not-consume=true.

Error invalid LOC header (bad signature) | jar binary

The Jar files custom or out of the box is important to be checked in as binary file into the version control system. If you check them into CVS or SVN as text files. It usually not a problem if your build process is on windows as windows is more forgiving about the file types checked in. If you use Linux or any UNIX based CVS\SVN servers. The build would through up with the error as below. The fix is either to override and check in the jar files as binary files or run some commands to change the type of the JAR files in CVS.


this is the error i am getting
[accessBeanRegeneration] +++ Warning +++:  java.lang.InternalError: jzentry == 0,
[accessBeanRegeneration]      jzfile = 164252568,
[accessBeanRegeneration]      total = 5,
[accessBeanRegeneration]      name = C:\WCToolkitEE60\workspace\WC\lib\custom\trimflt.jar,
[accessBeanRegeneration]      i = 1,
[accessBeanRegeneration]      message = invalid LOC header (bad signature)
[accessBeanRegeneration]      at java.util.zip.ZipFile$2.nextElement(ZipFile.java(Compiled Code))
[accessBeanRegeneration]      at org.eclipse.jdt.internal.core.JarPackageFragmentRoot.computeChildren(JarPackageFragmentRoot.java(Compiled Code))
[accessBeanRegeneration]      at org.eclipse.jdt.internal.core.PackageFragmentRoot.buildStructure(PackageFragmentRoot.java(Compiled Code))
[accessBeanRegeneration]      at org.eclipse.jdt.internal.core.Openable.generateInfos(Openable.java(Compiled Code))
[accessBeanRegeneration]      at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java(Compiled Code))

When is this file created ***Factory.java during the EJB creation process?

Answer after the access bean is created. If you haven't created entity bean for a while like me and you could almost forget. If you are looking at creating access bean for a session bean. It does not work with copy helper and you have to select the Java bean wrapper. After the access bean is created for session bean using New wizard, and select EJB > Access Bean and click Next.


Select the appropriate bean type for the session bean in this case would be Java bean wrapper.

Once you are done with the wizard, it creates the ****AccessBean.java and ***Factory.java and ibm-ejb-access-bean.xmi is updated.
Sample block from ibm-ejb-access-bean.xmi

If you just need to regenerate access beans, you can do the following and then deploy.

Java EE->AccessBeans --> Regenerate access beans
Java EE->Prepare for Deployment.


Just want to also quickly touch upon why access beans are required?
Access beans provide a simpler interface to clients, caching of the home object, and reduced call traffic to the enterprise bean and also encapsulates all the complex logic.
At run time the access bean caches the enterprise bean home object because look ups to the home object are expensive, in terms of time and resource usage.
The access bean implements a copyHelper object that reduces the number of calls to the enterprise bean when commands get and set enterprise bean attributes. Only a single call to the enterprise bean is required when reading or writing multiple enterprise bean attributes.

Reference:

http://publib.boulder.ibm.com/infocenter/wchelp/v6r0m0/topic/com.ibm.commerce.developer.doc/concepts/csdaccessbeans.htm

Websphere commerce--ERP data flow !!

For a lot of front end developers not working on integration, the ERP system is like a Black hole. This blog presents high level flow and integration touch points. As a part of most B2B and B2C implementation, it is generally important to communicate with a back end ERP system. 

The core of order management system in ERP has at least 3 main documents, Sales Order Doc, Delivery Doc, Invoice Doc. Sales Doc is used to create orders, delivery doc involves with shipping, Invoice with PO and settlement.

There could several other feeds and integration's depending on the operations in the end ERP system but most e-commerce system are fed Product\Pricing\Inventory data from back-end.  All this data being transported between the systems, could be implemented as Feeds\Web services\JMS-MQ .

Enterprise middle-ware systems such as Web Methods\WebSphere ESB\Open Source ESB could be for data transformations and communication with multiple systems.

Products\Price\Inventory--core of any commerce site and if it is driven from your ERP system, here's how the flow would be:

If the orders are dropped into the ERP system for order fulfillment at the high level, order tunnel flow from commerce to the backend system.