Discuss business intelligence, integration, compliance and a host of other SAP-related topics – implementation, best practices and resources to negotiate the world of SAP better!

« September 2011 | Main | December 2011 »

November 10, 2011

Architecture Plan for SAP Netweaver based Solution

Architecture for any IT based solution is a most important factor for aligning IT with business expectation. This also facilitates a transparent and manageable roadmap for most adaptable and efficient system landscape. An effective architectural design of a solution helps business to fulfill their target in an open, scalable and easy to handle infrastructure. This blog will focus on approach of an architecture design for SAP Netweaver based solution.

 Before starting an architecture design, first make a decision about the platform on which the solution will be built. As this blog is considering SAP Netweaver based solution as an example, the solution in discussion will be built on SAP Netweaver platform. First step is to consider Basic Architecture of the decided platform for the solution. It means the basic architecture of Netweaver based solution is briefed in a refrigerator-type diagram as shown below:

Ranjeet01.jpgOnce basic architecture is defined, we need to go through the use cases for the solution. Based on the use cases, the decision has to be made on component of Netweaver stack to be used for solution design. For example, use case says develop a User Interface which will be used to display analytical reports based of user's input data. Based on this use case, solution needs at least Portal, Business Intelligence (BI) and J2EE application server. This is the minimum component required to fulfill the use case requirement. So this is the second step for defining architecture for a solution and is called minimum infrastructure based on solution concept.
The third step is to finalizing different components required to implement this solution and is called minimum infrastructure with respect to SAP product. Different phases involved with solution implementation are Blueprint, Build, Execute and lifecycle management. In this step, SAP product has to be outlined for different phases of solution implementation. For example, to build portal based application, we need Netweaver Development Infrastructure to manage coding other than portal application server. Other different products might require are CTS+ for transport, NWA for administration and others.
Once all products decided for solution implementation, the last and final step is detailed solution deployment infrastructure. This step can be achieved by applying different architectural/deployment principles applicable for the selected products and recommended best practices for those products. Based on this step, an architect can revisit the decision made in previous step to give more effective design.

Below content showcases the points discussed above:

  1. Base Architecture(Solution IT platform)
  2. Minimum Infrastructure (Based on use case concept): Influenced by Solution Use Cases
  3. Minimum Infrastructure (Based on SAP product)
  4. Detailed Solution Deployment Infrastructure: Influenced by Architectural Principles, Deployment Principles and Best Practices.

November 9, 2011

Mobile Business Intelligence - Part 2

In the first part of this blog, we discussed key elements of Mobile BI, options for delivering BI content on mobile devices and business scenarios best suited for mobile usage. Now let's talk about specifics from SAP in this area. I will cover various technology options from SAP, their use cases, device support and some future enhancements from SAP.

Mobile BI is not new at SAP. Business Warehouse 3.0 offered what was known as BEx Mobile Intelligence. It facilitated rendering BEx Web Reports, developed using Web Application Designer (WAD), on PDA's and WAP-enabled phones. It had device recognition and rendering capability which meant that you could create one single template and use it on multiple devices.

The product was meant for early generation PDA's and WAP phones, and did not really come up to newer feature-rich and highly capable "Smart Phones". BEx Mobile Intelligence has not seen any new upgrades or enhancements in a long time. One of the reasons could be SAP's acquisition of BusinessObjects (BO) and its strategic decision to make BO as the primary Business Intelligence offering. If you are looking to start your Mobile Business Intelligence now, you should not consider BEx Mobile Intelligence as a strategic tool (it could be used a quick-win tactical solution though).

So what are the Mobility options on BusinessObjects toolset? At a high-level there are two; BO Mobile and BO Explorer Mobile. Both these serve different purposes. BO Mobile is meant to deliver targeted BI content to users based on their roles, whereas BO Explorer Mobile allows users to use search and exploration feature of Business Explorer via mobile devices. In other words, BO Mobile allows users to access predefined purpose-built BI applications from their mobile devices and BO Explorer provides them Google-like search feature to analyze data using auto-generated data visualizations on mobile.

BO Mobile enables accessing Web Intelligence (WebI) and Crystal reports content on Mobile through a device-specific client application (or "app"). It allows users to connect to BusinessObjects servers in the corporate network through mobile and render the reports that are already published on the server for that user/role. Although the reports have to be predefined, neither the data is not static nor are the reports "broadcast" to users. BO Mobile allows users to access the content on-demand (or "pull") and interact with it. Some of the key features it provides are document refresh, changing filter values (prompts), drill-downs, navigation to other hyperlinks defined on the report, invoking device-specific actions such as phone call, SMS text or Email, and sending document link via email, etc. It also allows users to receive alerts when a document is refreshed on the server or an exception condition is met. Users can also download report on the local device and access offline.

BO Mobile is supported on Windows Mobile, Nokia and BlackBerry Smart Phones. In June this year, SAP also released an app that allows accessing WebI reports on iPad. For iPad support though, you need BO 4.0 SP2 or BO XI 3.1 SP4 on the server side. Also, currently iPad only renders WebI reports (no Crystal) and some features like drilldown are not supported. But I must say that the visualizations on iPad look gorgeous!

Now let's talk about BO Explorer Mobile. This product extends the core search-and-exploration capability of BO Explorer to mobile devices. As we discussed earlier, the use case is completely different from BO Mobile. Here the objective is not to render pre-defined BI content, but to allow users to perform ad-hoc analysis. Visualizations are automatically generated by the system, similar to BO Explorer on desktop. However some backend work in terms of defining InfoSpaces etc. is still needed. You would need BO Explorer installed and configured on top of your BusinessObjects environment, and for a superior performance an accelerated (in-memory) version is recommended.

Currently the BO Explorer Mobile is available for iPad and iPhone as a downloadable app from Apple AppStore.

Both the above products do not address one key ask of many organizations and users - Xcelsius Dashboards. So how does one access Dashboards on the mobile? Well, there is one option. As most of you would know, Xcelsius Dashboards are rendered using Adobe Flash running in device browsers. So, technically, any device that can run Adobe Flash can render Xcelsius Dashboards. Users using Android devices (Smart Phones or tablets) or BlackBerry PlayBook can simply access Xcelsius Dashboards through their device browsers. As discussed in the first part, this is an example of RIA rendering. Only condition is that your BO Enterprise server should be accessible via Internet/VPN and device should support Flash. However as we all know, within tablet space, iPad is the big elephant, and since iOS devices do not support Adobe Flash, currently iPad and iPhone cannot run Xcelsius Dashboards. L

So as you might agree, SAP provides quite a lot of options and features to mobile enable your Business Intelligence. But I think there are some key elements still missing -

1.    BO Mobile support on iPhone (currently only iPad is supported)

2.    Drilldown functionality on iPad/iPhone

3.    Ability for users to customize charts/reports and save views

4.    BO Mobile and BO Explorer Mobile support for Android devices

5.    Xcelsius on iPad/iPhone

As per SAP, many of them would get addressed in the newer releases that are in "pipeline". (Disclaimer: product directions are subject to change)

Device support - Support for iPhone, Android devices and BlackBerry Playbook

Feature enhancements - Drilldown on iPad/iPhone

Explorer Augmented - Will integrate location awareness, device camera and map visualization in BO Explorer Mobile

Exploration Views - An extension on BO Explorer Mobile allowing users to customize and share different visualizations.

Unified Mobility Platform - An integrated platform for Business Process Mobility and BI Mobility. Currently both exist as independent product stacks (Sybase and BO Mobile) and technologies.

Well, that concludes this 2-part blog. In Part-1, we discussed generic aspects of Mobile BI, and in this part technology options from SAP. Hope you found them useful. Do write-in your comments/views/suggestions...


November 7, 2011

Regression testing automation in SAP: How to make it a success - Part - II

by Madhup Mukund Paturkar

In last blog we discussed about why regression testing should be automated. Also we discussed about the contents & important of Process Mapping and Test cases. In this blog we will look at the approach to automation project and tools provided by SAP.

Approach to test automation project:
The approach to SAP automation will also depend on many other non technical issues few examples are business process readiness, test case readiness and budget and time constraints.


madhup.jpg.pngAbove figure shows simple execution model for the automation project. Ideal way to do automation project can be with upgrade or any rollout where regression testing is being done manually. But before you start the automation project, it is expected that Process Maps are ready. Test case preparation and test data creation for the process along with automation can be achieved as a parallel process to any big project or upgrade. This gives saving of effort in terms of test data and test case creation. The same test cases and test data can be used in automation as well it helps to do the regression testing during big project or upgrade. To keep the momentum it is expected that you finish the automation project along with the regression testing of the already running project. Automation will always be lagging functional test data creation.

Operating model shows the tools used and data flow. It is expected that senior functional consultant to create detail business process flows. Based on the analysis of the flows functional consultant can create the test cases as explained in first blog. The variation of test data for a unique t code needs to be captured in test case. Automation team will need details of the flow and test data for the flow as well as test case. Test automation team needs a close co-ordination with functional team to understand the flow and variations. SAP experienced test automation consultant in this particular model is added advantage.

Tools required in test automation:
In order to run the entire project efficiently, you need tools like SAP TAO, HP QC, QTP and Solution Manager. ARIS is a tool provided by Software AG Company which has a very strong integration with Solution Manager. Process can be mapped in Solution Manager or ARIS-Solution Manager together. ARIS gives a very good front end for end users to understand the process and further enhance it. Purely from automation point of view ARIS is not mandatory.

Solution Manager has direct link with QC to create the requirements. Actual automation is done with help of SAP TAO and QTP. SAP TAO helps a lot in generating the components from SAP. Details about these tools are generally available on web.

November 1, 2011

Utilities can address Electric Vehicle Challenges with SAP Solutions

Electric Vehicle adoption is becoming a reality worldwide and it is growing at an accelerated pace. Automobile manufacturers across the globe are focusing on developing electric vehicles for mass consumption. The developed nations specifically are seeing this growth which is fueled by numerous factors like:

  • Electric vehicles are becoming more and more affordable. Coupled with innovative buying campaigns, it is driving purchasing
  • Lower cost of ownership of electric vehicles since these are not dependent of traditional fuels and simpler mechanical technology translates into lesser maintenance and failures
  • Increasing cost of fossil fuels since most nations are dependent on imports for such fuels and hence often consumers are opting for their small vehicle as an electric vehicle
  • Environmental concerns caused by use of traditional vehicles with some nations having high taxation on these
  • Rebates and concessions offered by governments in use of electric vehicles either directly or indirectly
While all this growth of electric vehicles is good for the economy, good for the environment and of course translates into additional revenue stream for automobile manufacturers, electric utilities are really concerned on how they can address the impact to their business, planning and supply of electricity by this increasing use of electric vehicles.

Charging an Electric Vehicle consumes and demands significant electricity when compared to the overall household consumption and average demand in a billing period. Hence increase in use of electric vehicle creates additional consumption and demand requirements. Some of the challenges that electric utilities are facing with the use of electric vehicles are:
  • Utilities are unable to plan additional consumption or demand from use of Electric vehicles  because utilities have no knowledge of number of such vehicles in a particular geography and at what time of the day these will be charged
  • Spikes in electricity demand can result due to concurrent charging patterns, sometimes leading to neighborhood blackouts
  • Meeting unplanned demand will require increase in financial, operational, field and planning resources
  • New services have to be introduced like public charging outlets and may have to be tied back to billing systems
  • Extra meters with line infrastructure and field personal may have be deployed to install dedicated meters in garage / parking areas
  • Standard household rates may not be valid for Electric Vehicles charging. Higher or different rates for Electric Vehicles may be required by some utilities or regulations
  • Changes may be required in bill print to show separate consumption for Electric Vehicles charging from regular household use
While the above are significant challenges posed by growing use of electric vehicles, there are possible solutions for utilities that are running SAP or planning to implement SAP based solutions.
  • Identifying additional demand and consumption requirements due to Electric vehicle use is important. Utilities can reach out to customers to understand their interest in Electric Vehicles and whether they are planning to purchase an electric vehicle in near future. The earlier the customers notify the utility, the more effective demand planning would be possible. This solution can be achieved in SAP in multiple ways:
  1. This communication can be created as a campaign in SAP Customer Relationship Management with a preselected target group. Based on the response the campaign effectiveness can be analyzed and reported. Further campaigns can then be modified accordingly.
  2. Bill Inserts via SAP Print Workbench or SAP certified products like StreamServe can help reach out to customers to gauge their interest in Electric Vehicles
  3. With SAP UCES, customer feedback can be recorded when the customer logs into the online portal
  • Utilities can tie up with Electric Vehicle dealers/sellers in their geography to notify the utility on sale of Electric Vehicles per geography. Using SAP, an Idoc based integration can be achieved with the Electric Vehicles dealer/Seller sending out a message with details of customer who has purchased the vehicle and his address . The same customer's details can be updated with relevant information in the SAP Master Data if it is also the utility's end customer.
  • Some utilities may want to have differential rates and tariff for Electric Vehicle charging. Using SAP's IS-Utilities Billing module will allow to setup differential tariff for such cases. SAP IS-Utilities Work Management and Device Management modules will allow a separate meter installation and dedicated meter reading management. Utilities may recover the costs involved in additional meter installation from the customer. This cost can be integrated into the regular periodic bill by using SAP's Sales and Distribution Module and IS-Utilities Invoicing.
  • Customer awareness campaigns can be executed to educate customers on charging their Electric Vehicles at off-peak hours. This can again be achieved using SAP CRM Campaign Management, Bill Inserts via SAP Print Workbench or StreamServe and SAP UCES.
  • Electric Vehicles can also be integrated into the Smart Grid. With this integration, utilities will have the ability to remotely disconnect Electric Vehicle charging to reduce peak load on the local distribution infrastructure. This solution can be achieved with SAP IS-Utilities AMI integration pack of AMI where remote disconnection services are provided.
  • Increasing outlets for public charging of electric vehicles will allow utilities to closely track and monitor growth and usage of electric vehicles in a geography. With SAP's Enterprise Asset Management modules, utilities can perform the entire blueprint to construction to maintenance of such charging outlets.
  • A customer using a charging outlet can input his Customer or Account Number prior to charging. With SAP Mobility solutions these charging outlets can be integrated to SAP IS-Utilities Device Management modules to capture consumption and the same can be billed and included in the periodic bill of that customer.
  • SAP Print Workbench and StreamServe can be used to enhance customer bill print by showing separate consumption and billing line items for electric vehicle usage.
  • SAP BI can be used to generate business reporting for electric vehicles. Some of relevant reports can provide insights into revenue by EV consumption, penetration of Electric Vehicles, forecast in growth of Electric Vehicles, Charging station utilization etc.
While Electric Vehicle challenges will continue to grow, with SAP based solutions, utilities should be able to address these challenges in a more effective and organized way and for a much longer term without having to incur significant significantly or bringing in 3rd party solutions.

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter