Archive for the ‘Business Intelligence’ category

The Building Blocks of Embedded Analytics

June 19th, 2017
Building Blocks of Embedded Analytics

Building Blocks of Embedded Analytics

The building blocks of embedded analytics.

What we wanted to share today was just a few of the universal truths that we’ve found over the last twenty years of studying embedded analytics and delivering solutions for our customers. Whether it is embedding on-premise data in a cloud application or creating a shared reporting service any analytics solution needs a few key features in order to flow properly. We conceptualise those features into six Building Blocks that your application will need to have. Some applications only have a basic functionality in any one block but will will go much deeper into others. For instance your application may be for internal user only and your company has standardized on Windows Active Directroy (AD) making Single Sign On (SSO) straightforward. However if you are maximizing the ROI and using your analytics for both internal and external application then additional SSO methods may be necessary. Likewise how you allow users to interact with the data may be performed pre-query results or post query results. Both methods has its benefits and drawbacks but no matter the focus of your application each of the building blocks needs to be considered up front.

User Authentication, User Interface, and User Interaction compose the first layer of an embedded analytics architecture.

User Authentication

The first building block for the application is to have a single sign on function capable of authenticating users from another application and or third party identity management system. In some way the identity of the user needs to be verified and passed into the analytics solution without the user being forced to login more than once.Or even login at all, in some cases .

The main point of the authentication process is to allow access to only the content that the user is authorized for has based on the security permissions they have been granted. After the user has been identified through the parent application’s security, their authorization gives them access to the business intelligence platform or analytics platform. The user interface for this is far better as a dynamically coded security protocol rather than a hard coded html page. For example as many users keep the ecosystem of their data spread out between the cloud and on-premise systems, two great standards for communicating between cloud based applications are OAUTH and SAML. These types of standards can help to securely pass the user authentication between the layers in your BI applications across cloud and on-premise networks in a way that is easier to support and expand on as standards change.

User Interface

The second thing the application needs to have is some type of report access. This could come in the form of a menu in the parent application. It could also be a list, or even something as simple as a link or button. The user interface simply functions to provide a user, once they have passed security, with access to reporting business intelligence content.

This method is often determined by the parent application or by the application that is delivering the analytical content. For Example some applications allow for simple links or a URL to be added where others will allow a tab of HTML content be added directly into the interface.

Example of Embedded Analytics

Example of Embedded Analytics

What you don’t want to do is build static html pages that are hard coded to reports that users should have access to execute. The reason for this is that, as your security changes and evolves with your software, it is much easier to implement dynamic security than hard coded security. So that the list of reports is dynamically updated, and so that, in the case of links or buttons are dynamically being updated in the user interface parallel with any changes made to the users security permissions.

It takes a bit more work to implement such a system, but it leaves the application far better equipped to deal with your evolving user base and the changes in security and permissions that entails .

User Interaction

A third thing your embedded analytics application needs is a form of interaction between the report and the user. Report interaction is where the user gets to decide what the content is within the information that they are getting back. Most often this feature is implemented through prompts. Prompts allow for parameter values that “act” on the query or report object to return on the information needed. Such actions occur before the report is run.

The user is asked through the interface what parameters they would like to place on the report such as date range, geographical area, or product line. This can shown as selectors on a screen and also be achieved through hyperlinks or drill filters coming in from the parent application. Note that the application needs to support that the prompts that are shown should only bring back a list of values based on the users level of access. This may come as part of the BI platform being connected to, but in some cases may not be available or it might be a clunky solution that requires the application to have that support explicitly added, along with with direct-to-data-source connections that adhere to any data security settings. For example, a sales person running a report with access to a specific area, be it geographically or organisationally, should only receive values pertinent to that area.

In the context of an embedded analytics solution the salesperson could have already clicked on the state of Texas within their map. At that point she is passing through the information she is looking to filter from her report based on what she selected in the parent application. Likewise, she or any other user, should not be able to change a URL and get access to data they are not entitled.

In a more advanced system you can control precisely what data within a report that a user gets access to see. As an example: if a VP of Sales user has no limits they legitimately need and are granted access to all the sales information across all regions and products for all times. But a limited user perhaps only gets access to information about what quantity of a product was sold and does not get to see the sales commission’s related to those product sales. Their access to information is limited by their security level. Where the application stores the security can be either the BI platform or the application. Each option has its own pros and cons in relation to how data interaction adheres to the security level of the user while providing the best performance.

Report Execution

In the second tier of embedded analytics architecture, there are three more key points for functionality. Report processing, storage, and distribution.

Firstly, report processing is where the really heavy work, in terms of actually generating the report, should be handled by the BI or reporting platform. The capture of information is generally going to happen through some type of query. This query may be connecting to one or more data sources. For example a report could be asynchronously connecting to a web service, a multi dimensional cube, a relational database, and a no-sql database.

At some point the system is going to be capturing the user input based on the requirements that you’ve specified in your report template. Based on the user interaction the report execution is going to be dynamically parameterized based on the report interaction and the user security. Once that data is captured it needs to be formatted. At this point the layout should be controlled by the template that you define in the BI platform to take that information returned from query and present that in the format that the user is looking for for making the decision prompting the query. An example of this is when drilling from a map to the underlying transactions shows as a cross tab by product by month for the city chosen. The layout , colors, fonts and display of totals were predefined in the report template. The data comes from the underlying query also predefined. The selection of state will have been sent at run time. All are necessary to create the expected output needed to make the next decision.

Report Output

The second part is the efficient storage of the data and metadata. At this point the end result of this report needs to taken and stored some place where the rest of the analytics process can take place. However, there is a lot of flexibility here and depending on your platform you could have several options. The storage location could be :
a) Returned to the user and not stored at all
b) Kept all in memory
c) stored on disk
d) a combination of the three.

Your requirements for Report Storage and Data Interaction will determine your preferred solution. Many platforms have restrictions on how information is stored so as to enable efficient search and retrieval processes. In other cases, especially where formatting is more important, or content needs to be accessed by users in static format, the output can be exported into network accessible storage and exported as Excel or PDF files.

User Data/ Interaction

Your application may have several requirements around the content once you get it back from the underlying platform, depending on what you want users to be able to do with it. In a highly interactive context the user will continue to author the report. This is where I, as a user, brought back the data and maybe I want to turn it from a table into a graph. Alternatively the data may be something that I just want to interact with it at different levels of a hierarchy.

An example of this would be where the report template brings the data back at a summary level, and I then want to drill through that information to the data underneath. This detailed data may be part of the original query and presentation, or it may require a secondary query or even a secondary execution of the report, parameterized further by the selection of the drilling activity. The earlier example of a map fits in well with this scenario

A third way of interacting would be filtering. In this case I’ve brought back a thousand rows, but to get the answer I’m looking for I need to filter that information.

Final Distribution

One of the reasons we do analytics and business intelligence is to help us make decisions that steer your business in the right direction. Distribution is the final piece of the puzzle that, based on your architecture, you need to determine “how do you want to exchange that information between users?”. At a basic level when saving the content do I get to choose whether it’s only accessible by my account or shared or access by my department. If the latter is true then should have ability to save that information in a way that secures it for users outside of my my department within the platform or in a network storage location with similar security controls.

The second option is to deliver the content. For instance: I’ve now understand this information and I want to email it out for someone else to view that may or may not have access to the application or BI platform used to generate the content. There are lots of different ways that distribution cab be accomplished such as emailing an excel spreadsheet or it bursting out spreadsheets every day by putting them out onto a website to be access by users with access.

In our next article we will go deeper into each of these areas of application design bringing out even more advanced embedded analytics application features.

Please feel free to comment and ask for the specifics of area that you are interested in more information on.

Answering the question of “Where?” Why our Partnership with Centigon matters

June 28th, 2014

As requirements for Geo Analytics continue to evolve and BI data sources expands to require cloud and on premise data the questions of “What” data to present and “How” to present it are answered with intelligence self service mapping application like CMaps Analytics.

The remaining question of “Where” to put the mapping interface and related reports and documents for users to find continues to challenge enterprises.

  • BI Platforms like SAP BusinessObjects and others have their own interface for managing and presenting content.
  • Corporate Portals are locations for information to be shared and collaborated on.
  • Cloud Platforms like provide cloud based web interfaces for sales operations and customer facing communities.

Where should the data go so users can find it, use it for making decisions and not require complex application development initiatives?  All of them.

Fortunately embedded analytics platforms our like Dashboard Launch answer the question of “Where?” and make it so easy it doesn’t require a developer at all to embed the map, report or dashboard into any and all of the platforms above where users go to access data.

Check out more about the expanded LaunchWorks Partnership with Centigon for bringing CMaps Analytics directly into using the embedable Dashboard Launch Application

The New SAP BusinessObjects RESTful SDK: What It Means to You

October 21st, 2013


Meet the LWLabs Team!

We here at LaunchWorksLabs are busy getting into all kinds of mischief. Most notably, the ins and outs of the new SAP BusinessObjects RESTful SDK.

If you are familiar with SAP BusinessObjects, then you know it is the leading global technology in the area of business analytics and business intelligence. This includes Crystal Reports, Web Intelligence, SAP Dashboards (formerly Xcelsius) and many others.

And if you are a Java or .Net developer, then you also know that SAP BusinessObjects has allowed developers to create custom applications solutions using their classic Java and .Net SDKs for years. We at LaunchWorks have been right there alongside you.

But there is a new kid in town: The BusinessObjects RESTful SDK.

Designed for Crystal, Web Intelligence and the BI Platform, the RESTful SDK (RSDK) is the next-generation application programming interface (API) for manipulating and interacting with Web Intelligence reporting residing on your BusinessObjects server.

So what does it mean to me?

For starters, it means no more jar files. Or, if you are a .Net developer, merge modules and or .dll files. The RSDK is based on a lightweight, refreshing platform that literally requires no installation. All it requires is knowledge of a handful of URLs and configuring your BOE server for web services (which is already configured by default). And you are in business.

And since interacting with the SDK amounts to http calls, it is als platform agnostic, meaning, it no longer matters whether you are using Java, .Net, PHP, Python, or even Javascript: The SDK is supported. And universal. That is: Gone are the days when there were differences between what the .Net version and the Java version of the SDKs could do (good news for .Net developers who suffered a dire lack of SDK support in the past few years). For these reasons, the RSDK is destined to replace classic Java and .Net SDKs in the coming months and years.

But this unleashed version has a bit of a catch. In classic Java/.Net SDK programming, as a programmer you would interactive with an object model. But with the RSDK consisting of no more than a vast array of URL calls, guess what? Your are the object model! Now this is good news on one hand, since your deployments will be as lightweight as you want them to be. On the other hand, building a scalable, maintainable, and robust enterprise application will require careful planning.

And that is where we come in :) Our flagship offering, the RESTful SDK Bootcamp, is designed not only to equip you with what you need to know in order to take full advantage of the SAP BusinessObjects RESTful SDK, but also to kickstart your custom RSDK project with coverage of best practices and proven enterprise development design patterns around the new RSDK. Basically, we have already done the hard part for you.

And we will continue to do so daily as we get into even greater mischief testing and exploring the capabilities of the new RESTful SDK.


Author: Don Collins


Lessons Learned from the 2011 BusinessObjects User Conference

October 16th, 2011

Just a few of the things that I learned at the User Conference

  • ASUG is actively creating great content in all areas of BI
  • The free access to ASUG fro BOBJ/GBN members is extended through 2012
  • The content delivered by experienced speakers is getting richer as 4.0 gets rolled out.
  • Make appointments with everyone you know is going to be there (I hit 5 out of 6 by scheduling times in advance)
  • There is an increasing desire in the user community to be heard, participate, and influence (See ASUG Strategic SIG for how)
  • Most companies still do not have a clear strategy for mobile BI
  • There are some very different ways to create enterprise BI systems that can scale globally
  • Tweeting consistently is hard work
  • I need an ASUG shirt
  • Lastly…
    The interest in the SDK is alive and well. For Non ASUG users that dont have access to our presentations our link is below.

    Kevin McManus

  • BusinessObjects SDK Best Practices

    May 23rd, 2011

    A series of the Best Practices that should be addressed when designing a BusinessObjects SDK Application.

    1) Where do I run the SDK in my application stack?

    There are 3 main architectures for SDK enhancement:

    a) InfoView Modification (i.e. hacking) – This involves changing and/or adding to the code that runs the InfoView application. While this seems like the shortest path it provides several challenges:

    i. The InfoView has several hooks for customization but not for things like changing menus, adding buttons, custom messages, etc.

    ii. Modifications will be eliminated as each BusinessObjects service pack, patch or upgrade is applied. This requires significant re-work, re-testing, and re-deployment procedures to be developed that could be used better elsewhere

    iii. This nullifies your support contract with SAP for the use of the InfoView at least.

    b) SDK Integration into a custom application – This involves adding the SDK libraries into the .NET or Java application that requires the enhanced functionality. The pro to this method is this provides a fully integrated application with connectivity Enterprise BI platform where you have full User Interface control and vendor support. The con to this choice include:

    i. The main application has been burdened with many additional libraries that must be integrated and deployed as part of its build process.

    ii. The main application has to be rebuilt and redeployed as each BusinessObjects service pack, patch or upgrade is applied even if there were no changes in functionality.

    c) Web Application Sharing (separate SDK application called from main application) – This architecture includes the same benefits of the first two options addresses the negatives of the prior two options while also allows a Service Oriented or Web Oriented Architecture where the functionality is available for reuse across multiple applications. The other benefits to this architecture include:

    i. The web server running the SDK application can be optimized for its use as a BI platform.

    ii. New BI functionality can be added as new BusinessObjects features and SDK’s become available with needing a build process and the related regression testing of the main application.

    2) Where do I run the SDK in my network stack?

    There are actually two answers in this area : For functions like authenticating the user, gathering a report and presenting a viewer there are both the Service Level SDK’s, as well as, a Web Services SDK. While the latter does not have all the same deep functionality as the service level SDK’s, it works extremely where in network architectures where direct access to the BusinessObjects server is not available. The Enterprise and related Crystal / Webi SDK’s use libraries that require direct IP access to the services running on the BusinessObjects Server(thin port 6400). The Web Services SDK can access the services through the web service application that can made available over the normal http access layer (think port 80)

    In terms of where should the application reside part of this best practice depends on your decision on the application stack above. If you are running an integrated SDK installation, then you need to install the SDK code on the same web application server as the main application. If you are going to create an shared application or just use the InfoView then it can run on the BusinessObjects server itself in the default web application server (think tomcat) or on a separate web application server (or cluster) specifically setup for web applications that can be called without logging into a single particular application.

    Another input to answering this question is the understanding of where the users that will use the application are located on the network and what access security is required to access the application.

    a) A publicly available URL (think will normally have at least one server in the DMZ(search demilitarized zone) where traffic can be monitored and direct access to the data is not required nor allowed.

    b) An internal application, or one requiring VPN access (search virtual private network) can have the web servers, Business Objects application servers, and database servers all on the internal network.

    3) Which SDK to Use for modifying Crystal Reports?

    There are two levels of “customization” when it comes to working Crystal Reports within the SAP BusinessObjects Enterprise system.

    a) When you need to add filters to your reports – This can be done using the Enterprise and Reporting SDK’s using the same features that allow you to add filters through the CMC in the report properties. This uses the normal Crystal Processing Server (i.e. previously known as the page server)

    b) When you need to modify your reports on the fly – This type of modification is deeper and touches the actual report object, although usually in the memory of the BusinessObjects Server. Examples of this type of modification uses the Report Application Server or RAS SDK to perform modifications such as add / remove fields, change database connections and handle the output of the report as a record set/stream/XML (in other words anything other than a viewer or export).

    Handling things like exporting the report content as a pipe (|) delimited file can now be done using the reporting SDK’s where earlier you would have to handle this through the slightly less scalable RAS SDK.

    4) Which SDK to use for modifying Web Intelligence reports?

    Until recently the only viable SDK was the ReBean SDK for working with Web Intelligence report modification. However….Recent updates to the Webi Extension Points has added a significant ability to customize the interfaces in both the web versions of Webi as well as the Rich client.

    a) When you need to add functionality to the Interactive viewer as the primary interface: – This can primarily be done using the Webi Extension Points along with some ReBEAN methods for managing output and storage

    b) When you need to add functionality using an alternative interface (i.e. simplified viewer) : the REBean SDK will give you all the power you need in 3.X. note that in 4.0 the ReBean SDK is more limited as there is a new Webi architecture underneath that will require subsequent versions before the full support through SDK’s is provided by SAP.

    5) Which SDK to use for managing the Security and Reports

    There are three main options for maintaining the security of the report objects

    a) Self Maintained – Where the main application stores the Users and reports along with the rights associated with those reports. This of ends in developing a reporting menu that has to be maintained so that it matches or is linked with the content in the BusinessObjects server.

    i. Pro: Integrated control of reports along with other application features

    ii. Con: Application security and reporting security are usually different and hard to match together. This usually ends up bloating the application security module needed to support reporting

    b) No-Security – The main application calls the reporting interface and users have access to all reports. Not a good long terms plan as business needs change often and things like providing use for users outside the company are not well supported

    c) Integrated : by using the strength of the BusinessObjects security as an authorization handler in coordination with the application authentication the best practice can be achieved.

    Is this valuable?

    SAP Crystal Reports Roadmap History

    February 24th, 2011

    When Crystal Decisions was purchased by BusinessObjects the Crystal Report designer tool was a Windows executable and had just integrated a full semantic layer that would allow multiple reports to access multiple connections and include multi-level business logic definitions in the form of a Business View.  BusinessObjects already had a mature Universe semantic layer as part of its platform and was already moving to a Java based report editor accessible over the web as well as on the desktop.

    While the BusinessObjects reporting tools becaome integrated into the existing Crystal Enterprise based server engines, the semantic layers remained independent.  Each tool’s implementation of semantic layer management was quite different and each had its strengths.  In the XI version Crystal could access both the Business View as well as limited support to connect to the same Universe but the integration stopped there.

    In the upcoming SAP BusinessObjects Enterprise release there is a new semantic  layer that begins to bring the best of the Universe and the Business View into a single Information Management tool.  SAP Crystal Reports for Enterprise will be able to take advantage of the new semantic layer in a consistent interface as it’s Web Intelligence and Dashboard Design (previously Xcelsius ) cousins.

    For connecting to other data connection types the SAP Crystal  Reports 2011 product will be released to replace its 2008 predecessor.  Later on these two versions will be combined into a single release.   Te get access to either you buy a single license…meaning by one and you get the other.

    Both  Crystal Reports for Enterprise and Crystal Reports 2011 are now also available as a Java application  that allows installation on Windows and Linux based desktop machines.

    Webinar: Leaping forward to offer your own SaaS

    November 18th, 2010

    We are very exited to present to the community what we have been doing since we first were certified as an SAP solution.  Beyond what can be presented on Ecohub or even our own web site, our customers have challenged us to leap forward in what BI concepts that Dashboard Launch can tackle for them.

    This webinar will challenge you to consider your own BOE system as a Software as a Service offering and what that means to how to offer advanced BI to your entire information supply chain.

    Feel free to contact me with any questions or ideas.  Registration links are below

    Kevin McManus
    McManus Software + Consulting.

    Internal (for SAP partners / employees with S User id):

    External (for customers / employees without S user id):

    Are people more important than technology?

    November 13th, 2010

    During a recent project review of an upcoming Enterprise BI / DW platform, one of the project tasks’s was to do an end to end tool selection. However, beyond technology the other aspects of a successful BI program necessary including people, process and data (ownership) were not properly being assessed.  The needs to properly assess and manage these areas would outlast any particular phase/sprint of development and would have an even greater impact than the technology.  With a brand new large BI program there will need to be new processes and new teams created in IT to make the current software in order to be effective in this program (note: projects end, programs evolve and change with the business, so BI/DW programs should be built and staffed that way from day 1)

    What was missing in the evaluation is the desired impact in the IT culture.  All of the solutions involved in the evaluation would demand a high level of experience, technical knowledge and creativity during the design and development in order to make it a success.  While the technical evaluations were sound, I wanted to see that there had been consideration of other non-technical aspects of a Data warehouse necessary to make the program and systems a success.

    Questions arose that needed to be answered

    – Is the expectation that business users will be connecting with Vendor support directly?

    – who is responsible for “quality” resource acquisition

    – Who is responsible for help desk models to support Business Rules, Data Miniing , etc

    – Who is responsible for ensuring that the quality of the data is kept intact over time from a technical architecture as the business change over time?

    – Who is responsible for ensuring that the knowledge of business rules are kept as assets?  An enterprise data warehouse/ BI system is a huge investment and that investment should be protected as an asset of the company.

    No matter what tool is chosen there are huge drains to a project, in time and quality, when users need to make business rule and solution design decisions on the fly.  This includes the creation of new business metrics, new reporting processes and mini-tool selections as new requests come up. (i.e. the users uses the excel export so they can recalculate a metric because the data warehouse team takes 3 weeks to get a change in place).

    One of the best practices to balance the projects technical needs with the people and processes is to establish a Business Intelligence competency group at the outset of the project that sits outside of any software or services vendor and has staffed BI/DW architects to can “rapidly” respond to the changing needs of the business with the “correct” solution and the ability to pull in the correct IT resources to meet that need at the speed the business needs before they feel the need to go out on their own.

    Podcast: SAP BI Consulting – Strategies, Tools, and Skills Trends

    September 6th, 2010

    ERP Lounge Jon Reed invited me to participate in “A Three Person Discussion of SAP BI Consulting Trends withSpecial Guests Vijay Vijayasankar and Kevin McManus” (ERP Lounge #12)


    August 29th, 2010

    We are going to host a Fall BI Mixer in Austin in September so we make sure we take care of everyone who has not been able to attend the San Antonio events. Location is going to be USTEL one of the predominent STBOUG members. Date is going to be confirmed. Let me know who can attend