Lawson Business Intelligence using Crystal & Underlying Data Architecture

Crystal can use native drivers to report off the relational tables or you can use the Lawson OLE DB Query builder.

The former uses no Lawson security. The Rights Management module in Reporting Services (one of the offerings in LBI package) give you the ability to build similar security relationships but keep in mind there is an administrative cost to this. Its not turn-key.

If you use the Query Builder, keep in mind that performance is poor and going across subsystems is difficult but it does use your in-place Lawson security.

As for Star Schema, there really isnt anything turnkey. Often we create reporting tables using different ETL tools but there are none that I know of offered by Lawson.

hth
matt

My question is really trying to focus in on the "operational business intelligence" that Lawson has presented which would enable "real time reporting".  For real time reporting are the out-of-the-box reports from Lawson going against the Lawson transactional tables or are they going against a star schema?

im not familiar with Lawson "operational business intelligence" offering. ive never seen any Star Schemas from Lawson so my assumption would be that they go against the transactional tables but thats just a guess. are you an M3 or S3 client?

We are S3.

Lawson "Operational Business Intelligence" is more to do with smart notifications which alerts the users and requests that an action be taken. All of the operational business intelligence sessions that Lawson offered at CUE were emphasizing the fact for smart notes and how they could be deployed on dashboards. Smart Notifications does not imply star schemas.
Operational BI also involes the scorecard and analytic architect and acc to Lawson this is a tool prebuilt in Lawson using hyperion essabase. The cubes about 12 come inbuilt with the analytic architect tool.

hth
Ruma.

Can anyone help answer the questions in my initial post? It would be highly appreciated!

MSSQL OLAP is also an option for Analytic Architect and Ive found that the "pre-built" nature of the cubes isnt as straight forward as youd expect. Its actually 12 Portal forms and you have to point the associated measures and dimensions to a source. One of the frustrations with this approach is that it doesnt lend to customization, addition or removal of the measures and dimensions.

Operational BI, as a concept, implies reporting off your real time data, typically this would exclude any star schema, reporting tables, data stores, marts or warehouses, unless you have a highly effective data transfer in place from your disparate sources. SN is good for this purpose because its meant to handle very specific information. Static reporting (Crystal) isnt ideal as it lends to large dataset reporting which can put a strain on your systems.

debika, I'm assuming you mean the Scorecard part of LBI (which doesn't use Crystal), not the Reporting Services (which uses Crystal)?

The Crystal reports are coming off of the transactional tables. Crystal uses the structure tables just like RW100 would. If you know how to join those tables you can use Lawson structure in any SQL reporting tool.

What time dimension are you looking for? Most tables in Lawson have a date or a period and year. Depending on the data you wanted to report on, you would just select the appropriate field.

As far as a star schema, it seems to me that it is very difficult to load incremental data from aggregate tables like GLAMOUNTS because you would have to query every record for a change to a specific field, not just add every record that is added to the table. Lawson does not provide any star schemas, you would have to define your own and the complexity would determine the timing. Even with Analytic Architect, Lawson does not provide a cube, cube builder, or ETL.

How is Crystal being used to access cost center hierarchy information?  My understanding was that basic SQL could not be used to extract the hierarchy information from Lawson tables as they are stored in Lawson lists (please correct me if I am wrong).  Can you explain how we can use Crystal to do reporting  (that requires hierarchy info as a dimension on a report) off of Lawson transactional tables? 

are you familiar with heirarchial groupings in crystal. the heirarchy in the lawson tables can be pulled in an heirarchial order using this option. The key is to link the primary field for eg: the supervisor reports to field in the employee field can be used for organizational heirarchy using the crystal heirarchial groupings.

cost center heirarchies are stored as different levels in the cost center structure. You can pull all the different level address information into your rw100 report. This RW100 report can serve as a data source for crystal. you can then group the different level address as an heirarchy.

Crystal can help create the cost center heirarchy.

k-rock, I have to disagree with you; the IA programs do create the star schemas, allow you to specify dimensions, etc. for the various data marts.

debika_sharma, going way back to the beginning of your post:

A number of reporting options are possible with LBI:

• From Reporting Services:
  • you can publish and/or burst 'back office' [COBOL] (e.g., GL290) reports. These can be used "as is", or used as a data source for a Crystal Report.
  • you can create your own Crystal reports which use the Lawson database tables as data sources
    • either directly connected to the database using a native database provider (e.g., Oracle or MSSQL). In the case of the native provider it has zero intelligence about Lawson data structures, hierarchies, relationships, etc.
    • or connected to the Lawson "database" via Lawson's OLEDB connector, which 1) applies Lawson security and 2) understands Lawson relationships
• But what I think you're possibly getting at in your original post (and what you saw in a demo) is NOT Reporting Services, but Scorecard, which uses Analytic Architect behind the scenes. Analytic Architect creates data marts for MSSQL OLAP/Analysis Services or Hyperion Essbase; when building data marts you specify various dimensions, etc. associated with--and specific to--the type of data mart. For instance, a turnover/headcount data mart would have a time dimension of "length of service" and you would specify how to calculate it, either via original hire date or adjusted hire date. It also understands organization hierarchies.