Parent Child Relationships in VBCs - BC User Property : "Populate Child Data"

Virtual Business Components provide for a nice way of presenting data via WebServices. Each time the VBC is loaded/refreshed in the UI, the integration is triggered behind it, and resulting response appears in the UI. But what if there is a parent child relationship in the data being returned and the requirement is to present each set of the hierarchy in a separate applet ? In normal BCs, the data is pulled from the tables, and if links are provided, the child BC gets refreshed when the parent BC is changed. How can we achieve the same in VBCs ? There is a little unknown BC userproperty “Populate Child Data”, which can be used to achieve this nice effect, without scripting, or repeatedly invoking the webservice. Here is what you do.

 

·         Create the two VBCs and the two applets for them. Also created the BO and View based on the BO.

·         Both the VBCs must refer the same IO,either via the BC userpoperty “Outgoing Integration Object Name”, or the IO name gets hardcoded in the WF.

·         The IO should have two ICs, one for parent level and one for child level in response data. The external names must be correctly populated with the BC names created.

·         Link must be created between parent and child BCs. This BC has to be added in the BO.

 

Now if everything is correctly configured, compile everything and fire up the client application. Navigating to the view will bring the data correctly in the two applets, correctly maintaining the parent child relationship between them. Moving to the next record at parent level will refresh the child level data, as the link is in context.

 

Now go ahead and check out the integration logs for this integration. There is a nice tutorial here.

 

You will find that the webservice integration was actually triggered twice, once for each level of hierarchy. The same request goes out and the same response comes back, so it means double the work. Now :

 

·         Go to the child BC you created. Add a new BC userproperty :

·         In the name column, provide : “Populate Child Data”

·         In the value column, provide : “Y”

 

Compile the BC and load the view again. Data still comes as expected in the UI alright, but if you check the integration logs, you will see that the web service was invoked only once.

 

BC user property “Populate Child Data” doesn’t look documented in bookshelf or supportweb. If you are not happy with this approach, there is a scripting alternative suggested on supportweb here.

 

 

 

Nice process, but what about the engineering bits?

Nice process, but what about the engineering bits?

via http://ayende.com/Blog/Default.aspx by Ayende Rahien on 2/19/10

Software processes has always been a popular topic of discussion in our industry. Those can get quite heated, with advocates of the "stable / stale" Waterfall method pointing fingers toward "rapid / rabid" Agile methods, with the CMMI people throwing documents around and Lean people standing on the sidelines muttering about Waste.

This isn't a post about a specific software process, I'll defer that to another day. Instead, I want to focus on a flaw in the basic building blocks in many* software building processes.

They ignore the actual building the software.

That may sound ridiculous on the face of it, after all, how can a software process ignore the act of building software. But take a look at the following diagrams:

If you'll pay attention, you'll notice that those processes talk about everything except how to actually build software. They talk about people, about requirements, about managing customers, about a whole lot of things, but not about the part where you have people sitting down and writing code. In most of those, in fact, that part is usually defined as one of those:

Why is that a problem? After all, isn't there a big distinction between software engineering (we know what to do, now let us do it) and project management (getting to know what we need to do, and verifying that we did it right). Those processes deal primarily with project management and leave the engineering part to be defined in a way that fit that particular project. Surely that is better, right? In theory, it might be. But there is a big problem when you have a software process that ignore the software engineering aspects of building software.

The problem is that that in many cases, there are hidden assumptions that are going to hammer you down the road if you use a certain process with engineering practices that doesn't fit it. Take a look at the following chart, showing a team velocity over time, does this look familiar?

The term I heard used for this is Scrum Wall, but I have seen similar results in other processes as well. The best description for that is Allan Kelly's:

You hit the Scrum wall when you adopt Scrum and everything goes well, then, after a few Sprints things don't work any more - to use an English expression, they go pear shaped. You can't keep your commitments, you can't release software, your customers get annoyed and angry, it looks like Scrum is broken.

This is what happens when you adopt Scrum without technical practices such as Test Driven Development, continuous integration and refectoring. When teams adopt the Scrum process, they go faster, show progress, things look good... and then the quality becomes a problem. Now the team are fighting through quick sand.

The code quality is poor and developers are expected to continue to make progress. Maybe the Scrum Master/Project Manager reverts to past behavior and demands overtime and weekend working. Maybe the team start busting a gut to keep their commitments. Either way the team is heading for burn-out.

The major issue is in focusing so much effort and time on project management with what amounts to willful ignorance of the technical and engineering practices will inevitably leads to disaster. The process of building software is intractably linked to the engineering practices involved in building the software. Moreover, some technical practices are actively harmful in some scenarios and life savers in others.

Many Agile and post-Agile processes focus on short cycles, each of them producing something with a distinct value to the customer. That may be an iteration, a commit or a feature, where the goal is to increase the velocity over time so we can provide as much value to the customer in as short a time as possible. What those processes ignore are things like technical debt, large scale refactoring and non functional efforts. Oh, you see those things mentioned on the edge, but they aren't something that is dealt with heads on, as a core issue to consider.

There is a bit more to that, actually. The software engineering practices and the project management strategies are linked and of paramount importance when the time comes to decide how the software should actually be built. No, this is not tautology. We just need to take into account Conway's law and expand on it a bit.

Any organization that designs a system will inevitably produce a design whose structure is a copy of the organization's communication structure.

Part of the design process of a project should include design the team(s) structure, the project management strategy and the software engineering practices in order to align the end result with what is desired. Ignoring this leads to imbalance in the project, and if that imbalance is big enough, and goes on for long enough, the project is going to rip itself apart.

* Nitpicker corner: I said many, not all. Don't bother to list me software process that deals with it. I had a reason to explicitly list the processes that I did.

Javascript trick to quickly navigate views.

Siebel’s hierarchical way of organizing views under sitemap is a useful feature, everything is arranged under screens as per context. But sometimes the only way to access a certain view is to go via the sitemap, and specially for administrators, this means sifting through pages of links to find the correct view. Being an Seibel EAI integration developer, I find myself frequently visiting three main views in Siebel application, on my local as well as the thin client. Most of my work can be done on tools, but Datamapper Administration View, Workflow process instance and webservice administration views are my mostly visited views.  Inorder to make navigation easier, I used to create bookmarks in the browser using the GotoView command to quickly take me to a view.

 

 

But this meant and different set of bookmarks for local client, and a different set for every server/environment. So I ended up using javascript to do the navigation for me.

 

Create a bookmark in your internet explorer, then enter the text below for Business Service Simulator view

 

javascript:var url = new String(window.location);var p = url.substring(url.search('start.swe?') ,url.length);p=p + 'start.swe?SWECmd=GotoView&SWEView=Business Service Test View' ;window.location(p);

 

Once you have logged into your siebel application (local/server), just select this bookmark , and you should be taken to that view.

 

Here is the bookmark for Datamapper Adminstration View

 

javascript:var url = new String(window.location);var p = url.substring(url.search('start.swe?') ,url.length);p=p + 'start.swe?SWECmd=GotoView&SWEView=EAI DTE Data Map Editor' ;window.location(p);

 

 

Code junkies can edit the code and add any view wanted.

 

Just discovered John Mayer

Just discovered John Mayer. Nice soft care free style.

Toy Story 3 - best movie of this year.

We have been through half of this year, and the only movie which stands out clearly is Toy Story 3. I have always loved animation. I love the way animators are able to make people laugh. But I am even more intrigued when they are able to turn people emotional, or even make us cry.  The first time I saw this was in Disney Pixar’s Up! There is a complete sequence of storytelling with moving images and soothing background music, but not even a single bit of dialogue, but it turns the viewer emotional. The only that stopped me from sobbing was that I was watching it at home, and not in the theatre.  And now , I had a similar feeling of nostalgia when I watched Toy Story, specially the ending. Again, there is no piece of dialogue meant for the viewer, it’s just animated sequences of last looks, and silent goodbyes. And music. Beautiful music.

 

At home, I still have some of my old toys, salvaged and preserved in the drawing room show case. It’s a bit of younger me. And old monkey my dad brought from Germany. A toy dog which still barks if batteries are inserted. The movie made me think, how did I feel when I outgrew my toys..sigh, don’t remember.

 

 

If you haven’t watched Toy Story 3- you are missing the best movie of this year……at least, so far.

sql update insert space before caps and capitalize first charachter

I was loading up EAILoolup Values for use in a interation module I had. The external values where strings without spaces and first letter of each word was capitalized.

 

Like this

 

reopenedOnClientRequest.

 

Its equivalent Siebel value to be show was

 

Reopened On Client Request.

 

So I figured all I needed was an SQL update statement to replace a space before each capitalized letter and make the first letter caps…

 

select initcap(regexp_replace(EXT_VALUE,'([^^])([A-Z])','\1 \2')) from S_EAI_LOOKUPMAP where LOOKUP_TYPE = 'ClaimStatus’

 

This did the trick !

4th Generation CRM system

I found this page on the net….it attempts to define a 4^th generation CRM system.

Today's Customer Relationship Management (CRM) System

It's impossible to state precisely what customer relationship management (CRM) means to everyone. The term has been applied to almost every element of business that even remotely interacts with a customer.

In its infancy, CRM systems were a series of mainframe or server-based applications specific to sales, marketing and support business functions.

The applications were lightweight by today's standards and did little more than capture and file critical data. But as cultural boundaries within organizations weakened, individual collections of information gave way to sophisticated applications that could span business functions. By doing so, these applications created the vision of a single view of the customer.

For the first time, organizations could track and analyze shifting customer needs, link marketing campaigns to sales results, and monitor sales activities for improved forecasting accuracy and manufacturing demand.

CRM's Evolution
CRM has evolved since its earliest incarnation, originally driven by an inside-out focus, through three phases of evolution: technology, integration and process. Recently have we seen a major leap forward to a fourth phase: customer-driven CRM —an outside-in approach that has intriguing financial promise.

1. Technology: In its earliest incarnation, CRM meant applying automation to existing sales, marketing, support and channel processes as organizations attempted to improve communications, planning, opportunity and campaign management, forecasting, problem solving, and to share best practices. To some degree, it worked. However, automating poorly performing activities or processes rarely improves the quality of the outcome. So, for the most part, the quality of the return on investment (ROI) was meager—if measurable at all. The promise of the technology was there, but few organizations were realizing the pinnacle of performance. The metric of success was increased efficiency in sales, marketing, support and channel processes.

2. Integration: By developing cross-functional integration, supported by data warehousing and shared roles and responsibilities, organizations began to create a customized view of the customer. Support issues, Web hits, sales calls and marketing inquiries started building a deeper understanding of each customer and allowed aggressive organizations to adapt their tactics to fit individual needs. Integration focused around two primary components:

• Make it easier to do business with the seller: Expected benefits are to improve customer retention and lower support costs.
   
• Predictive modeling: Data mining of an aggregate of corporate knowledge and the customer contact experience was used to improve operational and sales performance. By applying complex algorithms to a history of purchasing or inquiry characteristics, it became practical to predict the demands of individual customers. Up-selling, cross-selling, even the ability to preempt potential problems, was now possible for all customer-facing representatives. Expected benefits are to have better cross-selling/up-selling and improved product offerings or delivery.

3. Process: By rethinking the quality and effectiveness of customer-related processes, many organizations began to eliminate unnecessary activities, improve outdated processes, and redesign activities that had failed to deliver the desired outcomes. Then, by re-creating the process through an understanding of the capabilities of the technology, the outcomes were more predictable and the promises for a meaningful ROI more substantial and realistic. The metric of success became the improved effectiveness in serving the customer.

Thus far, almost everything about CRM has focused on improving the effectiveness and efficiency of the seller's organization.

Organizations have evolved from sales representatives working from paper notebooks, or a card system, to a tightly integrated network that sees movement in sales activity, predicts product demand on manufacturing, and manages the logistics of complex teams to serve the buyer and seller.

Marketing, support services, channel management, revenue management, resource allocation/management, forecasting, manufacturing, logistics and even research and development have all seen the benefits of a well-designed CRM strategy.

However, the past decade of CRM and its associated improvements have been based on three assumptions:

1. The past would be a logical foundation to predict future customer needs and profitability.

2. Demand for traditional value propositions would remain constant.

3. Better customer relationships would deter attrition.

All three of these assumptions have failed—or at least become unstable—in a post-September 11 environment.

Today we know that:

1. Historical purchases or inquiries are not a clear indication of future needs as buyers are rapidly redefining requirements to satisfy their current business, market or shareholder demands.

2. Value propositions are changing in highly competitive markets as sellers are working aggressively to reestablish structural bonds.

3. Driven by sensitive financial markets, buyers move to whichever supplier can provide the best aligned, most cost effective solution that promises to stabilize, or improve, their business performance.

These factors are driving CRM into a fourth phase.

Customer-Driven CRM—The Fourth Phase
Today, revenue performance has become the central theme for CRM as organizations seek to achieve and maintain expected financial results. Leading executives are asking:

• Which of my customers have the potential for a high-profit, sustainable relationship?
   
• What defines profitable and unprofitable customer segments?
   
• What must change to realize that optimal potential?
   
• Where's my opportunity for growth?
   
• Where's my risk for loss?
   
• Am I making the right decisions related to balancing acquisition, cross-selling and upselling—and for the right customer groups?

The epiphany isn't in the questions themselves, but in the fact that we're asking them after a decade of CRM investments—investments intended to provide just those very answers.

It is important to understand that a disruptive change has occurred causing large segments of customer organizations to reassess many of their basic needs, values and assumptions.

Research indicates that this event was triggered by the uncertain complexities of the post-September 11th world. Organizations are now challenging everything from how they create value, to how they serve their markets, to how they meet shareholder expectations. It is the answers to these questions that create the framework for phase four CRM.

Without a deep understanding of what's going on in the customer's head—specifically what will influence buying behavior—it is difficult to establish customer strategies that mutually serve the needs and expectations of the buyer and seller communities.

Understanding the Difference

In the past, CRM has followed a basic balanced scorecard technique involving four categories: customer, financial, operations, and people.

From an inside-out perspective, organizations first analyzed the needs and capabilities of operations and their people to determine what could be delivered to the customer.

From that, they drew conclusions and predictions to determine the impact on the financial category.

As this has changed, so have the priorities. Now the focus is first on the customers:

• What will they buy, when, why and for how much?
   
• What creates value for them, and does this create a structural bond?
   
• What services can we perform that merit premium margins?
   
• Can we establish a new market segmentation strategy focused on potential profitability and willingness to purchase?
   
• Do we understand their business drivers, financial metrics, buying process and decision criteria?

Customer driven CRM means that organizations first understand the customer, then move inward to operations.

Within the context of the customer, the systems and infrastructure capabilities needed to serve those customers and segmentation-based requirements must be reassessed.

Next, it's imperative to explore the skills and competency requirements for the people component of the CRM design.

A decade of CRM has taught us that nothing happens until your people interact with the customer in a manner consistent with new CRM customer strategies and systems.

And, finally, you should be well positioned to apply predictive modeling algorithms to establish a financial model with exceptional accuracy.

Not an easy task, but case studies are proving financial predictions that can demonstrate account-level forecasting with over 80 percent accuracy.

Summary

Developing a CRM strategy isn't an easy task. Complex organizational design, comprehensive technologies and ever-changing customer demands are just the beginning. The lessons learned are monumental but we know that the promises of customer driven CRM are worth the journey.

Here's a simple framework for fourth-generation CRM:

• Focus on financial results: Learn how to identify existing profitable customer segments and determine what will establish a profit-based profile for moving forward. Then develop the business requirements to support sustained, and structurally bonded, relationships.
  
   
• Find cost effective alternatives for nonbuyers or low-margin customers: Not all customer relationships are profitable and very few companies can afford to pay to deliver an equal level of services. Control costs and save your best resources for premium accounts—while working to bring low performers into an acceptable profit portfolio.