Perficient IBM blog

Subscribe to Emails

Subscribe to RSS feed


How Will IBM Utilize Silverpop, Unica and Xtify?

Michael Porter, Principal at Perficient, recently wrote a blog post discussing how Silverpop, IBM’s latest acquisition, fits into IBM’s strategy of reaching the digital marketer.

The enterprise marketing management space has been heating up for the past couple years.  IBM, Salesforce, Oracle, Adobe, and Microsoft have all made one or more acquisitions here and it hasn’t stopped.  Just a few days ago, IBM bought Silverpop, an Atlanta based cloud marketing automation player with customers in both the B2B and B2C space.

There is an overlap of features among Silverpop, Unica and Xtify, but Michael lays out how each platform will be maximized within IBM. To read Michael’s full article, click here.

Websphere Commerce: Returns and Refunds

Websphere commerce have Out of the box functionality of handling refunds on cancellation of an order and also returns. Here i am discussing technical details of handling returns and refunds of partial order, Like if you want to cancel only 2 items out of 50 items you ordered. Let’s say you have external Order management system tide up with websphere commerce, How can we handle returns and refunds.

This external system should communicate with services. Below are the steps one has to follow for accomplising this task.

  1. Lets determince the structure of the request. Websphere commerce provided order status service to communicate. Structure of order status can be found in Update_WCS_OrderStatus_30.dtd .
  2. Once we receive request XML that follows Update_WCS_OrderStatus_30 structure. WC will invoke command implementation for OrderStatusCmd.
  3. Create a custom implementation say XOrderStatusCmdImpl and update CMDREG accordingly, Ensure XOrderStatusCmdImpl extends OrderStatusCmdImpl.
  4. This setting will ensure order will sufficient for getting the request to the our controller.
  5. Few key points to remember is, Get refund policy id and refund payment method id
  6. We can get all the values from the request xml by calling  super.getOsProp(). This will give return TypeProperties.
  7. How can we map between XML and TypeProperties? That can be done by going through sys_template.xml
  8. Ensure order status is ‘X’. This is status for cancellation of order.
  9. Execute ReturnItemAddCmd
  10. Execute ReturnPrepareCmd. You can get Return item id from ReturnItemAddCmd (ex: returnItemAddCmd.getResponseProperties().getString(RMAItemId_0))
  11. If you want to update RMA items and RMA Item component use RMAItemAccessBean and RMAItemComponentAccessBean. I used RMAItemComponentAccessBean for setting shipment should recieve to ‘N’.
  12. Create RMA entry by calling RMAAccessBean. RMA should have total amount to credit and member id
  13. Now execute ReturnProcessCmd. finally do call super.doProcess(typedproperty). This will take care of changing the order status to X

Above steps will only prepare the data ready for processing the returns and refunds. You need to configure already exisitng scheduler job ReturnCreditAndCloseScan

The above steps will allow you to return partial order and refund partially.


Posted in Commerce

Implementing Omni-Channel Marketing Strategies

Managing large quantities of data and processes can quickly become overwhelming. In a recent blog post, Mark Polly, Director at Perficient, discussed five key strategies for omni-channel marketing.

IBM recently conducted a webinar titled “5 Key Strategies for Omni-Channel Marketing” in which they discussed the following strategies:

  1. Collect data that helps create customer profiles
  2. Analyze that customer data to find actionable insights
  3. Decide how to allocate your budget across the right channels to reach the right audiences
  4. Manage the interactions with customers across the channels
  5. Optimize your messages, offers, and capture reactions to feed the data collection process

To learn more about each of these key strategies, read Mark’s full blog post here.




Posted in Portals and Collaboration

Keeping up with the Fixes

A huge number of my projects are platform upgrades, and every time I ask my customers why they haven’t applied a single published fix for any of the products involved since the system was built (sometimes upwards of 7 years ago). They usually reply with a variation on the old trope, “If it ain’t broke, don’t fix it!” I of course launch into a sermon about the ways regular maintenance will save them from the pain of multi-version upgrades in the future, protect their data and users and save money by avoiding extended support contracts (see ATMs still run Windows XP).


Reading a recent Flash (Alert) from IBM brought this perennial conversation into clear focus. I think it’s a perfect example of why keeping up with the patches is absolutely critical. IBM’s Enterprise Content Management products, as a whole, have Java Applets in their front-end applications for viewing and annotating images and a bunch of workflow features (design, administration, configuration, simulation, etc.). These Applets rely on the user having the Oracle JRE installed on their workstation, which, of late, has been a moving target in terms of security requirements. The latest versions (1.7.0_51 and above) will block most of IBM’s Java Applets because they were developed to older standards. As the Flash indicates, a series of Fix Packs and Interim Fixes have been released to address this issue.

Read the rest of this post »

JMeter Testing for a Datapower ESB Implementation – Part 1


When considering testing a Datapower implementation the first tool that is generally mentioned SoapUI. While this is a good tool for a particular aspect of testing, you may need to expand your testing capabilities to include a broader set of concerns. In this blog I’d like to consider an architectural scenario in which I will need to cover a range of architectural patterns.

The Architectural Components

Datapower deployed as a single component in in the architecture provides very little in terms of the need for a testing a solution. For this example I’ll consider the following architecture. A Datapower XI52 deployed as an ESB. Websphere MQ for protocol mediation, LADP for authentication and authorization. The client will use RESTful calls with transformation between XML and JSON. An FTP server has also been added to the scenario. O’yes the webservce is Soap based. Finally, I have two Datapower application domains, what I’ll call DEV-DEV deployed on Port 5400 and DEV deployed on Port 5420. This could also be DEV to QA or staging. This basic architectural configuration will cover the following Datapower patterns;  MQ to MQ; HTTP to MQ; MQ to HTTP; Datapower LDAP integration; Datapower FTP Integration; Many to Many Transformation; Soap WS integration; RESTfull to Soap integration;

The Test Plan

I’m in the early development phase of my project, and I need to setup some unit tests;

1. I want to place a RESTful GET call to the appliance and evaluate the Response
2. I want PUT & GET  messages from Queue’s
3. I want to be able to either a) use or b) by-pass the Datapower ESB to get a file from the FTP-Server
4. I want to call the Active Directory and get back the DN
5. Call A webservice operation using HTTP transport
6. I’d like to do some preliminary load testing

Read the rest of this post »

Creating Custom/User Defined Node in WMB/IIB

Why User Defined Node?
At one of our Large healthcare client, there were multiple SIEMENS Invision Interfaces which use SNA (Systems Network Architecture) for inbound and outbound communication.
SNA is a set of protocols and services enabling communication between host computers (Mainframes) and other servers such as Windows/AIX/Linux.
Websphere Message Broker does not have predefined nodes for SNA communication, and therefore custom nodes were created for SNA Inbound and outbound communication from Message Broker.
(Plugins are written using CPI-C for Java).

Steps for User Defined Node Creation:
1. Create a User Defined Node Project (File -> New -> User-Defined Node Project)
2. If the node falls into existing set of categories select that, otherwise create a new Category. This drives where the node will be displayed in your Toolkit Pallet.



3. Create a new User Defined node, select whether you want to implement it as Subflow or implement it in Java or C.


4. You can choose specific icons (This has be a gif file with size 16×16 or 32×32)
5. Add appropriate Terminals and Properties.
6. Write your code in implementation project. Node name declaration connnects the implementation project with actual node project.
public static String getNodeName() {
return “SNAInputNode”;

Installation of Nodes:
1. Export the node project as User-defined node plug-in
2. The node project needs to be extracted in the directory TOOLKIT_INSTALL\plugins
3. Export the implementaion project as a Jar file
4. Implementation jar file needs to be placed to following directories.
5. In case you change the implementation code, jar file needs to be exported and replaced in the directories mentioned in #4. For the code change to reflect you will have to restart the execution group which is using this node.

1. For using the WMB exception framework you should always have ‘catch’ and ‘failure’ terminals to all nodes. Names of these nodes are case sensitive, they should be completely in lower case.
2. If you are writing code for inbound node which is listening on input make sure it releases the control to WMB at certain intervals using TIMEOUT, otherwise you will not be able to stop the message flow.


Posted in News

Sequence Diagram in WMB

Using the WMB toolkit we can produce a sequence diagram with the following steps.

  1. Open Modeling Perspective

2. Within this Perspective Click on File->New->Other


3. Select Sequence Diagram within Modeling profile

4. Click Next and Select the location where the File needs to be created and Click Finish. A work area with the palette of nodes will be provided to build the diagram. A sample screenshot of the same is below.



A SOA Journey Using the TOGAF ADM – Part 3

In this article I address some of the the final elements and models in this iteration of the Preliminary phase. At this point I would like to comment about the ADM as an iterative process. In regards to Architectural Definition which includes an ideation / inception iteration. At this point in the role of Business Architect I have taken some time to consider each phase of the ADM in preparation for the next iteration. For the most part I have started to what are the possible artifacts that will be developed in the subsequent iterations. For this I generally use a heat map styled document for planning and charting progress. This artifact provides a planning snapshot for upcoming gate reviews as the transition made between iterations. Up to this point I’ve only lightly touched on the some of the essential aspect of architecture effort with a focus on governance. It should be noted that the degree of “doneness” for any particular artifact that has been produced up till this point will vary. And because I am publishing the repository content as Web documents from the modeling tool. Stakeholders are not constrained to a particular deadline for reviewing the content of the EA repository.

This is a type of model driven approach where the repository is used for dynamically doing architecture development. This is a concept that will require time for organizational socialization, and the shift in organizational behavior may be slow. This is an aspect of the TOGAF that I opted not to cover in this series. But organizational change should not be underestimated. However, the benefits of this approach are significant in that it promotes agility as a capability as well as an organizational behavior. Mgt-HeatMap.png

One key value add for the artifact development heat map, is that is can be easily used in conjunction with agile project management methods. For example, aligning the heat map with PM methodologies provides a means for enabling the use of the architecture artifacts, and governance checkpoints, and can serve as the basis for creating architectural epics. This is also my way of creating a plan for integration points for introducing new SOA capabilities into the already established business planning, portfolio, and operations management frameworks. For example, by the end of this article I will have developed an architectural definition that will address the integration points of Architectural Direction, Structured Direction, and Architectural Governance. The heat map will provide me with measure of the degree of completeness that is needed to satisfy these framework interfaces. Read the rest of this post »

IBM Pure Application Implementation Guide

I have been several calls with customers that are interested in the IBM PureApplication Systems. Once the customer is taken through the standard canned sales presentations and then a Demo there doesn’t seem to be much more guidance available. The next step is always a Business Value Assessment(BVA) but they usually take a long time and require large amounts of information from the customer. Information the customer may not want to provide during the early stages of discovery. The document I have attached uses scenarios to give further guidance on the practical uses of PureApplication. The intended audience is the customers technical staff.

IBM Pure Application Implementation Guide

Posted in News

A SOA Journey Using the TOGAF ADM – Part 2

In part 1 of this series I provided a ten thousand foot view of the project relative to the TOGAF ADM. In this post I’ll start with the proverbial peeling back of the onion. Using an integration project FYI Bank has made a strategic decision to address the challenge of their silos of IT systems by separating out their processes into business functions. One eerily business driver is the need for FYI Bank to improve business agility to respond to regulatory and market changes. The goal is to move the enterprise towards an infrastructure of building blocks of predefined services. To achieve this business executives of FYI Bank have also decided that a SOA strategy will best help meet this goal. The Bank’s executive steering committee has determined, that an attempt to implement a common enterprise architecture approach across the entire financial system would take a significant amount of time and effort, but they also believe that it is an achievable goal. Especially if the business organizations adopt a shared set of business and IT standards to ensure that a flexible SOA is possible. The steering committee has also approved the Lending Services organizations proposal for a Loan Application Portal Integration project,  which is the pilot project for the SOA initiative. Additionally, FYI Banks Infrastructure Design Authority has selected to use IBM’s WebSphere Datapower SOA appliances as a new enterprise platform services capability. The enterprise architecture team has been engaged to support this organizational change to SOA and the introduction of this new technology component.

As the assigned architect responding to the business request for EA, I’ve identified some preliminary EA objectives around SOA governance. Now I intend to provide several model representation that will both inform and reflect architectural decisions going forward, as well as provide a new SOA governance capability around the architectural decision processes. One set of objectives is that the governance model will be developed incrementally, and will provide a reasonable set of constraints and compliance checks in the development of the business capability, and solution architecture. The measure for these objects has not been fully identified at this time. So the model representations that follow in this article are parts of what will be a comprehensive look across the architectural continuum. I’d like to encourage the reader to take a some time to review the various models. Their purpose is to communicate architectural decisions, by presenting various model views and perspectives in TOGAF and UML notations as well as observing the syntax of these notations. Which is an important part of doing architecture development..

With that statement in mind I’d like to bring up the subject of architectural modeling and tools. While it may feel a bit disjointed from the flow, I believe that it is an important aspect of the article, since I’ve already mentioned that you will be seeing several modeling representation, and more importantly these representations are guides for doing architecture.

Over the years of reading enterprise architecture blogs, and participating in various EA efforts. The topic of modeling tools has often been discussed. Sometimes it seems more like a religious debate, and I’ve read statements that a tool is somewhat superfluous to the EA tasks at hand. From my perspective I believe that a good tool is important to any craftsman, the mechanic, the carpenter, and yes enterprise architect. In order not to come across as dogmatic or bias about any particular EA tool. I feel that it’s more important to have a reasonable and specific list of requirements. I’ve taken this short list from RFP’s on previous EA projects.

…..The tool shall provide a comprehensive coverage of several modeling notations.
………..(UML 2.0, Archimate, BPMN 2.0 and TOGAF elements and stereotypes)
…..The tool shall  provide a comprehensive coverage of modeling diagrams.
………..(TOGAF, UML, Free-form)
…..The tool shall provide support for the TOGAF ADM.
…..The tool shall provide relational management of modeling elements.
………..(Supporting model element integrity, and object reuse)
…..The tool must provide a content repository, preferably relational database.
…..The tool shall provide a means of publishing the model as Web content.
………..(Not necessarily providing a proprietary Web application client)
…..The tool should provide constraints and guidance on modeling syntax.
…..The tool should provide a flexible means of structuring, packaging and ordering of model elements.

The importance of this short list of requirements will become even more apparent as we transition through the ADM phases, but at this point I have another objective, which is to build a repository of reusable and relate-able artifacts that I will be able to use across the ADM iteration and the development life-cycle of the project. Another objective is to elevate our modeling representations above a academic, and Marka-tecture presentation approach, and use a rich set of notations that go beyond the notional Box & Line diagrams. All of which tend to be pasted into word documents and templates, that become stale soon after their release. In my thinking EA model representations should be iterative, dynamic, near real-time, and reference-able and reviewable by a larger audience at any time; preferably made available via a Web based reporting capability. Because ultimately the goal of the EA is to provide more that just architectural representations. The EA should also use the TOGAF ADM as a tool to guide the development of  a set of prioritized and aligned objectives, and to provide the means for continually evaluating the understand the organization and its architectures, as well as to communicate this understanding to stakeholders, while moving the organization forward to its desired state.

So as a way communicating the FYI Bank Enterprise model. I have structured a repository as work packages that follow the TOGAF framework. In this regard a work package is a container that holds model representations as artifacts used in the implementation of the SOA governance capability. As the naming convention I will use the TOGAF phases as the parent work package. These will contain viewpoint packages, which are containers for model views. Model elements have will have meta-data attributes which will be present viable at some level in the fleshed out the designs. I will also provide a comprehensive view of the models published as Web documents. To give you a little more context I’ve included the following textual representation. The section labeled Model Diagrams  represents a combination of TOGAF and UML model diagrams that are both reference-able and reusable as project artifacts. These are generally positioned at the package root level as they often provide different perspectives of the work package content. Again, I will post the evolving model as Web documents in upcoming blogs.

A-Package.png FYI Bank Enterprise
EA Context Model View

A-Package.png Requirements Management
……..A-Package.png Enterprise Architecture Requirements Viewpoints
……..A-Package.png Project Level EA Requirement Viewpoints
…………….A-Package.png Portal Integration EA Viewpoints
A-Package.png Preliminary
……..A-Package.png Content Meta-Model Viewpoints
……..A-Package.png Logical Layer Viewpoints
……..A-Package.png Principles Viewpoints
……..A-Package.png SOA RA Meta-Model Viewpoints

Note: Model Diagrams

Repository Content Model View – Loan Application Portal Integration Project
Project Structure View
Content Meta-Model View
Principles Model Domain View
EA Principles Model View

A-Package.png A. Architecture Vision
A-Package.png B. Business Architecture
A-Package.png C. Information Systems Architecture
A-Package.png D. Technology Architecture
A-Package.png E.Opportunities and Solutions
A-Package.png F. Migration Planning
A-Package.png G. Implementation Governance
A-Package.png H. Architecture Change Management

Now let’s return to the project at hand. At present the FYI Bank has an enterprise architecture practice and several components of the TOGAF framework and ADM are already in place. In previous ADM iterations the EA team has established several core principles across multiple domains. The current enterprise organizational context is fairly well understood. Business frameworks such as Portfolio and Operational Management are also in place. Now the task ahead of the team is to introduce new capabilities for a SOA style architecture, as well as building the business solution for the Loan Application Portal Integration project. To guide the creation  of the FYI Bank’s SOA governance model I’ll turn to the Open Groups SOA source book. The source book is the Open Groups collection of source materials for use by enterprise architects working with Service-Oriented Architecture. The documentation of the work being performed in this area of TOGAF can be found at; If you have not already read the source book, you may want to take a moment to read through the introduction and become familiar with the framework of the documentation. I’d like to also note as a reminder, that I will be using both the Source Book and the TOGAF 9 framework throughout the project. The obvious implication of introducing the SOA source book  is that the Loan Application Portal Integration project now has two areas of architectural concerns. The delivery of an effective business solution, which will be based on SOA governance standards provided in the new EA capability.

crop-small-prelimRecalling from the first blog the TOGAF ADM “crop circle” we were looking forward to the Preliminary phase where I would begin establishing the “where, what, why, who, and how we do architecture” in the enterprise. Since we are dealing with a change to our architecture practice we’ll start by turning to the TOGAF 9 Architecture Capability Framework for guidance and inputs. In reviewing the categories of the capabilities framework we see that this iteration of the ADM will impact the current design of all four domains of the architecture: Business, Data, Application, and Technology. I followed this activity with a review of the UML package model diagram, which outlined the Loan Application Portal Integration project structure, so I am now informed about which work packages will also impacted. A detailed explanation TOGAF’s Architecture Capability Framework Part VII can be found at:

While examining the scope of change I’ve created a new Repository Content Model View, which is an abstraction while evolving the initial context for the next set of activities. Within the Preliminary phase work package I’ve now added a work packages for our new EA SOA principles, a EA requirements work package, a content-meta model view, to the Logical Layer Viewpoint, which has been reused in from our previous EA work. I’ve also identified the new EA capability as TOGAF SOA Governance.

In developing this model artifact the scope of the architectural change becomes more evident, in particular the change will impact the roles and responsibilities of several actors; business SMEs, business architects/analysts, and the architectural concerns covered by solutions/data/security/ technical architects, as well as system and software designers. In terms of roles and responsibilities and the decision as to what will be included in this iteration is still an unknown and under consideration at this time. What is known is that there are skills that are not outlined in the EA skills matrix.

Repository Content Model View.jpgLoan Application Portal Project – Project Structure View

The next category that I will cover in the capabilities framework is Architecture Compliance. Of the two subsections of compliance I start with a focus on the function of architecture, since this area addresses project-specific views of the enterprise architecture as used throughout all phases of the ADM. Here I will introduce what I consider a first class contextual model for the EA effort; the content meta-model. While the TOGAF Framework provides several excellent representations for this model. In my humble opinion, the significance of this model cannot be underestimated. So I’ve have included a content meta-model representation as part of our repository as an entity relationship diagram. I will use this model as sort of a planning tool, as I consider what objects will be included in the iteration, and the task that will be needed to develop those objects. If I’m required at some point in the project to provide a .mpp like project plan, I will use the content-meta model to flesh out the tasks for a work breakdown structure.

So throughout the execution of the ADM this artifact will play an important role in terms of planning EA activities, as well as maturing the EA content repository as we implement new business and architecture capabilities. During a previous EA project, a business stakeholder commented that at first glance; the content meta-model seems overwhelming, potentially producing a sense of “sticker shock”, or just too much information. My explanation was, that the model may be viewed as an object oriented version of a PM work breakdown structure, or it can also inform other agile PM methodologies by providing stories and task. For example, taken as a whole, the content meta-model is the basis for architectural epic. In a future blog I will suggest how a EA efforts can be integrated into a larger scale agile approach, as an architectural epic.

Content Meta-Model.jpgContent Meta-Model View

In the next model I will layout a Domain Principles Model Viewpoint, which provides us with another contextual view. I’ll use this to contain, communicate, and manage newly added SOA principles. Again we already have reusable work packages from previous iterations of the ADM. In this preliminary phase activity I’ve added a Principles of Service Design work package, which we saw was added to the Repository Content Model View. This also gives me traceability and scope by accounting for EA activities that will be used to flesh out the details of this work package. The principles that are added to this work package become a vital part of SOA governance.

Domain Principles Model Viewpoint.jpgDomain Principles Model Viewpoint

Next I’ve started by adding several new model objects that are stereotyped <<principal>>. These elements are now part of the EA principles catalog as principle statements, along with the Rationale. These principles will be referenced and applied in the both the next phase, and future phases of the ADM. With he expectation that I will be  adding more principles to this work package.

 Service Design Principles View.jpgService Design Principles View

Given the significance of content meta-model, and the various newly added model artifacts. I’d like to suggest that we take a pause and review Part IV of the TOGAF framework. In Part 3 of the series I will build out more of the preliminary phase, by delivering the next version of the repository, I’ll link in Business Principles, Business Goals, and Business Drivers. We’ll add more details around SOA Governance, and I’ll then flesh out the details around the Architecture Definition Artifact. This will lead to a transition into the Architecture Vision Phase, where we will take up the decision to introduce IBM® WebSphere® DataPower® Integration Appliance as a strategic technology enabler for SOA.