Wednesday, 27 August 2014

Websphere Commerce outbound message configuration with Wbsphere MQ


Outbound messages are sent from WCS to back end system (for e.g.: Emails, MQ messages etc)

Out bound messages can be created in two ways

1. The first method is to build your new outbound message in your own String buffer and assign it to the outbound messaging system through the use of its message content setting services that set the message content directly. This alternative requires you to include the logic of building the message in the controller command that you write.

2. The second method is to build your new outbound message through the use of the outbound messaging system composition services. Through the use of JSP pages, the composition services generate an outbound message according to the message layout and content you defined in the JSP page. 

Steps to Create Out bound message using second method  as mentioned above(JSP Composition Method)

1.Create a new controller command or customize an existing task command to send a message with a certain message ID or name.
2.Add a row into MSGTYPES table assign a msgtype_id with a new viewname, based on the command
3.Create a new row with the name in Struts-ConfigExt.xml and assign the devicefmt_id, and JSP page
4.Create a profile in the PROFILE table using the Administration Console, and assign the message type to the correct transport (for example, e-mail) and device format (for example, standard device format).
5.A valid device format ID, as specified in the Struts configuration file, must be specified for each transport to be used. This device format ID (for example, DEVICEFMT_ID) must match with the one added into Struts configuration files in order to be able to pick the right JSP template file for composition. 

The following are the values you should use in the Struts configuration file:
a.SOAP XML data transmitted via HTTP = -1
b.HTTP Browser = Reserved for IBM
c.Standard Device Format = -3
d.WebSphere MQ Adapter for XML = -4
e.WebSphere MQ Adapter for WCS (Legacy message) = -5

Create a messaging system object using the SendMsgCmd task command.

Invoke the SendMsgCmd.execute() method.

Steps to Create as follows

Create Sample controller command for sending user details to MQ using the second method (Using JSP composition method)

public class PushUserDeatilsCmdImpl extends ControllerCommandImpl 
implements        PushUserDeatilsCmd {
public void setRequestProperties(TypedProperty reqProperties)
                   throws ECException {
firstName = reqProperties.getString("firstName").trim();
lastName = reqProperties.getString("lastName").trim();
}

public void performExecute() throws ECException {

LOGGER.debug("ENTER");
super.performExecute();
SendMsgCmd sendMsg = (SendMsgCmd) CommandFactory.createCommand(SendMsgCmd.NAME, getStoreId());
sendMsg.setCommandContext(getCommandContext());
sendMsg.setStoreID(getStoreId());
// MSGTYPE “UserDetails”should match  with entry created  in MSGTYPES table
sendMsg.setMsgType("UserDeatils”");
//UserDeatils View  is the Jsp which will compose the messge
SendMsg.compose("UserDeatils View", getCommandContext(),getMessageViewProperties());

// This will send to MSGSTORE table first
sendMsg.sendTransacted();
String UserDetailsSuccessView = "UserDetailsSuccessView";
sendMsg.execute();
TypedProperty respProperties = new TypedProperty();
respProperties.put(ECConstants.EC_VIEWTASKNAME, UserDetailsSuccessView);
setResponseProperties(respProperties);
}

Make StrutsConfig-ext.xml file changes

<action path="/UserDeatilsView " type="com.ibm.commerce.struts.BaseAction"/>
<forward name="UserDeatilsView/0/-10" path="/StorefrontAssetStore/Messages/UserDeatilsXML.jsp" className="com.ibm.commerce.struts.ECActionForward">
 <set-property property="resourceClassName" value="com.ibm.commerce.messaging.viewcommands.MessagingViewCommandImpl"/>
set-property property="properties" value="storeDir=no"/>
<set-property property="interfaceName" value="com.ibm.commerce.messaging.viewcommands.MessagingViewCommand"/>
<set-property property="implClassName" value="com.ibm.commerce.messaging.viewcommands.MessagingViewCommandImpl"/>
<set-property property="direct" value="true"/>
</forward>

<forward className="com.ibm.commerce.struts.ECActionForward" name=" UserDetailsSuccessView /10001" path="/StorefrontAssetStore/User/UserDeatilsSuccess.jsp " />

Make MSGTYPES  Table entry

Add a row into MSGTYPES table assign a msgtype_id with a new viewname, based on the command

Make PROFILE Table entry 

Create a profile in the PROFILE table using the Administration Console, and assign the message type to the correct transport (for example, e-mail) and device format (for example, standard device format).
 
Create the composition JSP,UserDeatilsXML.jsp

<?xml version="1.0" encoding="UTF-8"?>
<%@taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
<UserDeatils>
<FirstName><c:out value="${WCParam.firstName}" escapeXml="true"/></FirstName>
<LastName><c:out value="${WCParam.lastName}" escapeXml="true"/></LastName>
</UserDeatils>

Create the Success JSP,UserDeatilsSuccess.jsp

<%-- Print success message--%>




Tuesday, 26 August 2014

Websphere Commerce JSP Inclusion Methods



JSP Inclusion Methods: Can be classified into two types

1. Using include directive /Static Include (eg:  <%@ include file="relativeURL" %>)
2. Using Include Action (eg: jsp:include)  and <c:import  url=" filename.jsp"/ >

Static include

Static include directive causes the content of the specified file to be textually inserted into the including file at compile time, that is, when the JSP page is translated into a Java servlet. JSP elements of the included file are thus effectively visible anywhere in the resulting JSP page and must have unique names to avoid name clashes. Typical Web containers are unable to detect changes made to the included file at run time, and hence the including file needs to be updated for the changes to take effect. The syntax for the static include directive is as follows: 
<%@ include file="StaticFile.jspf" %> 

Dynamic include

Dynamic include actions include the response generated by executing the specified page during the request processing phase, that is, when the including page is requested by the user. Since what is included is the response generated by the page, and not the content of the page itself, scripting variables declared in the included file are not visible elsewhere in the resulting JSP page. Changes made to the included file, on the other hand, are transparent to the including file. Two alternatives exist for the dynamic include: 

<c:import url=" DynamicFile.jsp"> ... </c:import>
<jsp:include page=" DynamicFile.jsp" flush=" true/false"> </jsp:include>

Unlike jsp:include, the c:import action provides a mechanism to access resources that can be specified through a URL, thus allowing page authors to get access to resources that reside outside the Web application. On the other hand, it lacks the ability to flush the response. Finally, c:import is comparatively more heavyweight and is therefore not appropriate when a lightweight solution is sought.

If your WebSphere Commerce site uses Dynamic Caching, you must flush the response. To do so:   Precede and follow every c:import action with a <%out.flush();%>

out.flush statement is required for all <c:import> statements, not just those for fragments. Even if the page is being cached using full-page caching, the out.flush tags are required to surround the <c:import> tags.

When using the JSTL import tag, the JSPWriter buffers the data. It does not flush the data to the cache's writer. Because of this buffering, dynacache does not know when the application stopped writing the data to the parent writer. As a result, the child's content might also be cached as part of parent cache entry, and causes the child fragment to appear twice. 

To prevent this problem, surround the <c:import> tags with <% out.flush(); %>. You flush the buffer before the import begins, and after it ends, to ensure that none of the child content is written to the parent's cache entry.
Flush attribute controls whether any current output is flushed (sent to browser) prior to including the content from the included file.The fact that we must flush the output buffer limits what we can do with the <jsp:include/> action. In particular, using response.sendRedirect() to another page is no longer possible. Likewise, setting cookies or HTTP Headers will not succeed. This applies to both the files involved: the including file and the file that is included.

The 'flush' method of out object is used to flush the buffer by writing the contents to the client.

Out.flush();
<jsp:forward  page =forwardpage.jsp&”>

In the above example, no forwarding will take place. This is because of the "out.flush()" method. This method will flush the "JspWriter" buffer. Once the content is written to the browser, a forward cannot be invoked. 
 
You can store <c:import> in a variable <c:import> might do some type of full read before printing to output, whereas  <jsp:include> uses buffering. This could show a performance difference for very large files, with <c:import> requiring longer and taking more memory to get all the data in the import whereas <jsp:include> did things with buffers.

Static include vs  Dynamic include

The syntax for static include is <%@ include file=”filename.jsp” %> and the syntax for dynamic include is <jsp:include page=”filename.jsp” /> 
Static include is an inline inclusion. i.e., the contents of the file will be included at translation phase. It’s something like a copy and paste . In case of dynamic include the response of the file will be included to the original response at runtime. The file will be processed separately and only the response will become the part of the original files’ response. 
Static include cannot have a dynamic filename. This is because the servlet container needs the files for inclusion, at translation phase itself. But dynamic include can have a dynamic filename. Here the file is getting included at runtime.Static include cannot accept a parameter But dynamic include can accept a parameter.Static includes are faster than dynamic includes.