With Data Services 3.2 being out of maintenance and headed for End of Life, I’ve been involved in more and more upgrades to Data Services 4.x. Depending on your requirements, both Data Services 4.1 and Data Services 4.2 are available as upgrade paths. There are some interesting differences and some gotchas that I’ve discovered through […]
As a company we are always trying to further our experiences, give back to the user community and solidify our place in the marketplace as experts throughout the SAP BusinessObjects suite. Having presented at user conferences in the past, we are always looking to continue that trend and submit abstracts for as may as we can. This year at the 2013 ASUG SAP BusinessObjects User Conference in Anaheim, Ryan Muldowney and I will be presenting a session on the best practices of when and where to combine multiple data sources.
Data Services 4.0 is currently in ramp-up with SAP. Just like in the new BusinessObjects version, there are a lot of changes to be seen here. Overall it is much more tightly integrated with the BusinessObjects platform, providing a much more streamlined and consistent user experience. Here’s a taste of what’s new.
I recently published the post 5 Reasons Why You Should Use an SAP BusinessObjects Universe to highlight some of the core benefits you’ll see when implementing the semantic layer for you organization. The post was derived from speaking with organizations new to the Business Objects world about the benefits of leveraging the semantic layer. Throughout those talks, I also get to hear a lot of misconceptions about SAP BusinessObjects Universes. Sometimes they are born out of a simple lack of understanding of the SAP BusinessObjects architecture, while other times they are propagated by competing business intelligence vendors. (Shocking, I know.)
In meeting with organizations who are new to SAP BusinessObjects or who are legacy Crystal Reports users, we are often asked the question “Why should I use a Business Objects Universe?”. To organizations who have worked with universes for a period of time, the advantages and value proposition are clear. But for organizations who are new to universes, it can often be a challenge to quantify the value of the semantic layer.
In this post I hope to outline a few of the reasons why we recommend implementing universes, even if you’re not using an SAP BusinessObjects tool that specifically requires them.
Finally after three projects and three months later, we are back to finish up our Aggregate Awareness series. In part 1 of our blog, we discussed the definition of aggregates and how to create summary tables. Today we are going to finish the process by showing how to implement these items into a SAP BusinessObjects Universe.
Following SAP’s big acquisition of BusinessObjects, more and more companies running SAP are looking to BusinessObjects as an answer for their reporting needs. The BusinessObjects tools WebIntelligence and Xcelsius are well suited for this role. However, getting SAP data into those tools is not yet as easy as SAP would like. For a variety of reasons, BusinessObjects Data Services is the tool of choice for extracting data from SAP. In this post I will explain how Data Services talks to SAP to extract data.
In the SAP BusinessObjects community, when someone talks about “AA” they don’t mean the meetings people attend, they are talking about a pretty cool function that is available in Designer. Aggregate Awareness or @aggregate_aware is a term that we use to describe the ability of a universe to utilize aggregate tables in a database. Using the function correctly can greatly improve the performance and user experience. This will be the first of two blogs and will talk about Aggregation and Summary tables. The second post will show how to implement Aggregate Awareness into a SAP BusinessObjects Universe.
Back in March I posted “Five Reasons Why Ad Hoc Reporting Won’t Work In Some Organizations”. In that post, I listed some of the major concerns that I hear from potential clients when the subject of ad hoc reporting is broached. As promised, I will be addressing each of those concerns and showing how they can be overcome. We’ve already addressed “Our people aren’t smart enough to create their own reports.” Now let’s turn our attention to data, and look at “We need to massage the data first.”