1. Integrating Crystal® and your OpenEdge™ Application
Martin van Middelkoop
Sr. Consultant, Business Intelligence

2. Agenda Crystal products overview Progress data  Crystal
Progress apps  Crystal
The presentation is built up in three parts:
First a short introduction in how Crystal Reports can be compared to other products in the market, and an introduction into the key components of the Crystal Decisions product suite. Then, a jump start to the next two parts will be made by describing the process of Report generation and usage.
The second part will be all about how to get data in Crystal Reports from a Progress database. Various options exist, which are all talked through with the pro’s and con’s.
The third and probably most extensive part will be all about how to let your Progress application control Crystal Reports.
COMP-12 Integrating Crystal and Your OpenEdge Application

3. Scalable for Functionality
Java™, .NET™ & COM
Free Runtime Distribution
license
Crystal Explorer
Relevance / Reliability
BOBJ
Enterprise
Ad-hoc web reporting
CR Server
Standalone
Scalability
CR Dev
Max 20CAL
Server
Web
Scheduling
Security
Now, let’s take a look at the different products available from Crystal Decisions. We’ll start at the bottom line and go up the line offering more functionality and reliability step by step.
From a functional perspective.
CR Professional is intended only for the single user developer – distributing reports is not possible / allowed. So this is a version for customers who want to create their own reporting layouts or adjust the layouts offered by their ISV.
CR Developer – this is similar to CR Pro, but allows you to distribute report layouts together with an ActiveX runtime to refresh and view reports. Typically this is the entry point for an ISV who wants to distribute reports with their application. Note: In CRXI one copy of CR Developer must be sold to every customer where the ISV application is sold and distributed to – up to Crystal 10 this was a free runtime.
CR Advanced has disappeared in CR XI – the extra data access options and Report Creation API’s have been included in CR Developer now. A 5 CAL Server component is delivered with each CR Developer
CR Server is a combination of CR Developer and a 5 concurrent user Server – this was called Crystal Enterprise Embedded Edition in Crystal 10, but includes security and scheduling on top of this. Up to 4 CR Server licenses can be purchased to serve 20 concurrent users, but installation is limited to a single server with maximum 4 CPU’s.
Crystal Enterprise has been rebadged to BusinessObjects Enterprise, and offers scalability to more users and servers, and failover.
Crystal Explorer is an extension offering ad-hoc Web Reporting based on datasets defined by IT specialists.
We will look into the CR Developer and CR Server area mostly, but it has to be said that CR Server definitely is the way to go. This is the only integration option which can be migrated easily to BusinessObjects Enterprise.
One remark / disclaimer: the exact functionality available in various products differs slightly with each version. E.g.: In CR 9 CR DEV offered a 5-user production level Report Application Server (aka Crystal Embedded, aka CR Server), in CR 10 this is not the case anymore, and Crystal XI again includes a 5 Named User introductory offer of CR Server. On the other hand the modifyable report API was offered in CR 9 on a per-user basis, where CR 10 bundles this with CR Advanced for free, and Crystal XI includes it in CR Developer. This presentation talks about the CR XI license structures, and about the big picture – in detail some differences will exist.
CR Pro
COMP-12 Integrating Crystal and Your OpenEdge Application

4. Integration options Crystal to Progress® Progress to Crystal
Data security
Reuse 4GL business logic
Progress to Crystal
Refresh & view reports
Modify report layouts
Let the user create layouts
Web integration
In the next two parts, we will discuss these subjects in more detail. Note that the implementation which serves your situation best depends on which Crystal products you are using. Especially Ad-hoc or Web based reporting and Scheduling set their own demands on how to get data from Progress into Crystal.
COMP-12 Integrating Crystal and Your OpenEdge Application

5. Agenda Crystal products overview Progress Data  Crystal
Progress Apps  Crystal
This brings us to part 2 of this presentation.
Crystal Reports offers many ways to access data, as you can see on the right hand side. I want to discuss three major techniques here:
ODBC
XML / Text files
ADO.NET OpenClient access
Java Beans OpenClient access
COMP-12 Integrating Crystal and Your OpenEdge Application

6. ODBC Most common way of data access SQL statement SQL92 Crystal
Reports
SQL92
engine
Resultset
Crystal
Server
ODBC is the most common way of data access for any BI application. Where ODBC had a nasty reputation in the past, it currently is nothing more than a wide open gateway right into the database engine. No translations, no transformations, no performance hits are imposed by this ODBC layer when it comes to Progress.
BI applications typically use SQL statements which are sent to the SQL engine, the SQL engine gathers all the data and sends it back as a ResultSet to Crystal Reports. This works fine for all versions of Crystal Reports – Crystal Reports Pro, Developer, Advanced, RAS, and Crystal Enterprise. It works fine for ad-hoc querying as well.
However, it has some downsides as well. You need to install and configure ODBC on each client. And if ODBC is configured, this opens up the database to any other application as well, or you will have to implement database security again in the SQL92 engine.
If you are developing or have developed a Progress-based application, with all it’s business logic and data security implemented in 4GL, why do this again in SQL? It might prove to be impossible (some things in 4GL are hardly or not doable using a single SQL statement). At least it is hard – you know 4GL very well, but probably not SQL. And the SQL92 engine has completely different characteristics as the 4GL engine; you’ll have to learn all that.
Client
Server
COMP-12 Integrating Crystal and Your OpenEdge Application

7. ODBC Works with all Crystal products
Most common way of data access
Works with all Crystal products
Easiest to implement ad-hoc option
Most flexible approach
Re-implement data security and logic in SQL
ODBC install and configure on each client
Wizard usable in all scenarios – more details in former Crystal presentation:
ODBC is the most common way of data access for any BI application. Where ODBC had a nasty reputation in the past, it currently is nothing more than a wide open gateway right into the database engine. No translations, no transformations, no performance hits are imposed by this ODBC layer when it comes to Progress.
BI applications typically use SQL statements which are sent to the SQL engine, the SQL engine gathers all the data and sends it back as a ResultSet to Crystal Reports. This works fine for all versions of Crystal Reports – Crystal Reports Pro, Developer, Advanced, RAS, and Crystal Enterprise. It works fine for ad-hoc querying as well.
However, it has some downsides as well. You need to install and configure ODBC on each client. And if ODBC is configured, this opens up the database to any other application as well, or you will have to implement database security again in the SQL92 engine.
If you are developing or have developed a Progress-based application, with all it’s business logic and data security implemented in 4GL, why do this again in SQL? It might prove to be impossible (some things in 4GL are hardly or not doable using a single SQL statement). At least it is hard – you know 4GL very well, but probably not SQL. And the SQL92 engine has completely different characteristics as the 4GL engine; you’ll have to learn all that.
COMP-12 Integrating Crystal and Your OpenEdge Application

8. ODBC
COMP-12 Integrating Crystal and Your OpenEdge Application

9. OpenEdge Reference Architecture
Users
Users
Enterprise Services
Enterprise Services
Crystal
Presentation Layer
Presentation Layer
Crystal
Integration Layer
Integration Layer
XML export / Open Client
Service Interface and Environment Utilities
Business Entities
Business
Tasks
Business Workflows
The OpenEdge Reference Architecture recommends to build your application in layers. If we look at the ODBC option to get data, we are effectively by-passing all layers and go directly to the database. Wouldn’t it be better if we could see Crystal as just a possible Presentation Layer and then use a Service Interface to retrieve data using the existing Business Logic and security?
Data Access Services
Persistent Storage Services
Managed
Data Store
Unmanaged
Data Store
COMP-12 Integrating Crystal and Your OpenEdge Application

10. ADO.NET XML Files Most simple way to reuse business logic & security
Server/ CE
Crystal Reports®
XML
XML
Progress App
AppServer™
The route presented here is most commonly and successfully being used by quite a number of Progress Partners. It is easy to implement, and offers you complete control over the data needed by a report; both performance and security are completely 4GL related.
Typically, a Progress App retrieves a TempTable, SDO or ProDataSet from an AppServer (or without using an AppServer). This dataset is then transformed on the client side to an XML file. XML has the benefit that the data is surrounded by tags, telling Crystal Reports (or whichever user of the data) what the data means, what the datatypes are, and even what the relations between the parts of a nested XML file are. However, it is not the most efficient way of storing data – some partners prefer to use CSV (Comma Separated Values) files instead. The concept is exactly the same, though. After the file has been exported, the Progress App tells a Crystal component to open a report layout, and use the XML file as an input.
This can be done in multiple environments, also when using a RAS server to display the report in DHTML form. However, Crystal Enterprise scheduling cannot be used, nor can we do ad-hoc reporting outside the Progress application – we allways need a Progress Application to start generation of the XML files. This can be considered to be a drawback as well as a benefit, ofcourse.
Scheduling can be arranged using a Progress scheduler, and for ad-hoc reporting one would like to have a mechanism in the application which allows the user to construct datasets on an ad-hoc basis within the Progress App, and then starting Crystal on basis of that dataset. Some partners already have built such an ad-hoc “querying” mechanism in their application, which took some work ofcourse, but now offers the best possible speed and flexibility to their end users. We will talk about the front end on this solution lateron.
TempTable
ProDataSet
Client
Server
COMP-12 Integrating Crystal and Your OpenEdge Application

11. ADO.NET XML Files Some overhead Usable in 2-tier, 3-tier and 4-tier
Most simple way to reuse business logic & security
Some overhead
Usable in 2-tier, 3-tier and 4-tier
Only Push from 4GL, no Pull
The route presented here is most commonly and successfully being used by quite a number of Progress Partners. It is easy to implement, and offers you complete control over the data needed by a report; both performance and security are completely 4GL related.
Typically, a Progress App retrieves a TempTable, SDO or ProDataSet from an AppServer (or without using an AppServer). This dataset is then transformed on the client side to an XML file. XML has the benefit that the data is surrounded by tags, telling Crystal Reports (or whichever user of the data) what the data means, what the datatypes are, and even what the relations between the parts of a nested XML file are. However, it is not the most efficient way of storing data – some partners prefer to use CSV (Comma Separated Values) files instead. The concept is exactly the same, though. After the file has been exported, the Progress App tells a Crystal component to open a report layout, and use the XML file as an input.
This can be done in multiple environments, also when using a RAS server to display the report in DHTML form. However, Crystal Enterprise scheduling cannot be used, nor can we do ad-hoc reporting outside the Progress application – we allways need a Progress Application to start generation of the XML files. This can be considered to be a drawback as well as a benefit, ofcourse.
Scheduling can be arranged using a Progress scheduler, and for ad-hoc reporting one would like to have a mechanism in the application which allows the user to construct datasets on an ad-hoc basis within the Progress App, and then starting Crystal on basis of that dataset. Some partners already have built such an ad-hoc “querying” mechanism in their application, which took some work ofcourse, but now offers the best possible speed and flexibility to their end users. We will talk about the front end on this solution lateron.
COMP-12 Integrating Crystal and Your OpenEdge Application

12. XML
COMP-12 Integrating Crystal and Your OpenEdge Application

13. Open Client Most elegant way of integration Server/ CE Open Client
Java / .NET
Crystal Reports
Open Client
Java / .NET
AppServer
TempTable
ProDataSet
TempTable
ProDataSet
If we look at this XML / Text file option, it has two drawbacks:
We need more processing on the client side, transforming the Progress data to XML
We need intermediary files – after all, this is all writing to and reading from disk, and thus expensive
Wouldn’t it be nice to retrieve data directly from an AppServer BusinessLogic component, using in-memory communication? Crystal Reports could use an ActiveX or Java Bean component to connect to the AppServer, the AppServer can handle all BusinessLogic and security. This can be used in a 3-tier architecture, but also very easily in an Crystal ad-hoc or Scheduling architecture, eliminating the need for a 4GL scheduler or ad-hoc application.
This is the only 100% OERA compatible solution, where Crystal is a Presentation Layer, independent from the Progress App Presentation Layer. Therefore, in our opinion, this is the preferred way of integration from a Data Retrieval perspective.
proxy.p
Client
Server
TTitem.p
TTitem.p
COMP-12 Integrating Crystal and Your OpenEdge Application

14. Open Client 100% OpenEdge Reference Architecture
Most elegant way of integration
100% OpenEdge Reference Architecture
Usable in 3-tier and 4-tier
Usable without Progress application push!
ADO.NET implements ProDataSet
Java client implements TempTable
If we look at this XML / Text file option, it has two drawbacks:
We need more processing on the client side, transforming the Progress data to XML
We need intermediary files – after all, this is all writing to and reading from disk, and thus expensive
Wouldn’t it be nice to retrieve data directly from an AppServer BusinessLogic component, using in-memory communication? Crystal Reports could use an ActiveX or Java Bean component to connect to the AppServer, the AppServer can handle all BusinessLogic and security. This can be used in a 3-tier architecture, but also very easily in an Crystal ad-hoc or Scheduling architecture, eliminating the need for a 4GL scheduler or ad-hoc application.
This is the only 100% OERA compatible solution, where Crystal is a Presentation Layer, independent from the Progress App Presentation Layer. Therefore, in our opinion, this is the preferred way of integration from a Data Retrieval perspective.
COMP-12 Integrating Crystal and Your OpenEdge Application

15. Demo ADO.NET Open Client
COMP-12 Integrating Crystal and Your OpenEdge Application

16. Java / Temp Table
COMP-12 Integrating Crystal and Your OpenEdge Application

17. Data Connectivity Options Summary
ODBC
XML
ADO
.NET
Java
Pull + -
Ad-hoc ++
BusinessLogic/ Security reuse --
Config/deploy +-
2-tier/3-tier/4-tier
234 34
COMP-12 Integrating Crystal and Your OpenEdge Application

18. Crystal products overview Progress Data  Crystal
Agenda
Crystal products overview
Progress Data  Crystal
Progress Apps  Crystal
Now, let’s see what we can do on the Progress – Crystal integration!
COMP-12 Integrating Crystal and Your OpenEdge Application

19. Integration Progress  Crystal
Various client and server options
COM
CR OCX
Viewer
ASP/JSP
In this part of the presentation, the Progress App is the central object. We will discuss a lot of different integration options with client-side and server-side Crystal components.
The first integration option, widely used by many partners and customers, is the Crystal Reports OCX/ActiveX Viewer, in combination with the so-called RDC: Report Development Component. For many tasks this is a free deployment option as long as you (the partner or IT department) have bought a CR Developer or CR Advanced license. This option allows you to open up an existing Report Layout, change the datasource, change parameters and run the report (this is all RDC stuff), and then show the report inside a Progress window in the ActiveX viewer, allowing you to control all functionality through your own buttons, using events, etceteras.
Note: a part of the 850 function calls of the RDC is available only when you deploy a Crystal Advanced license to each installation. This offers functionality like changing the Report Layout on runtime, adding or deleting components, or even build Report Layouts from scratch on runtime.
The RDC Browser application, downloadable from Crystal Decisions website, describes all the available function calls for both the RDC as the Viewer OCX.
The last client-side option we have is the Designer OCX, bundled with CR Advanced. This OCX allows you to construct a dataset or connection from your Progress App, and then let the end-user use a CR Pro-like interface to construct the Report Layout. Almost all functionality is available, except for some details (see the documentation / website for more details). A Wizard DLL is available, too, to allow you to guide the users to (parts of) the Report Creation Wizard.
On the server side, it’s another story. We have two different components, which are closely related: RAS and CE. RAS is named CE Embedded Edition in CR 10, and uses the same 2 API’s for many aspects, but CE offers 2 extra API’s.
First, there’s a COM interface, to let you application talk with RAS and CE, very similar to the RDC type of interface, but now focused on Server based layouts. This is a typical Client/Server solution, allowing you to let a RAS refresh a report layout and then use the OCX Viewer to view it. This is the successor of the RDC API – it allows you to think big, deploy small, but then be able to grow to larger deployments!
Then, we have an ASP/JSP webinterface, using plain URL syntax to put a server component to work and view the resulting report in a DHTML or ActiveX viewer. We need ASP or JSP here, because the ASP or JSP pages are actually using the COM or Java interface on the server end – we need some extra server processing on the web server.
Crystal Enterprise offers a possibility to accept URL’s directly without the need for programming anything, and furthermore CSP pages or a WebService. CSP pages are a major subset of ASP language, but can run on UNIX (and Apache or Netscape webservers) as well, and offer more options to place the workload to other servers than the web server.
Finally, CE can be used as a WebService, offering a completely platform independent interface for application integration. Using the OpenEdge Webservices access, integration is very easy.
CR RDC
CR Server
Progress
App
URL
Creation
CSP
CR OCX
Designer WS
Client
Server
COMP-12 Integrating Crystal and Your OpenEdge Application

20. Progress – Crystal Wrapper Ideas
OLE interface to Crystal Reports®
OLE interface to Crystal Enterprise
Generic 4GL interface for use with or without AppServer™
Example application
COMP-12 Integrating Crystal and Your OpenEdge Application

21. Demo Crystal API’s
COMP-12 Integrating Crystal and Your OpenEdge Application

22. Very loosely coupled interface Viewrpt.csp (Crystal Server Page)
URL Syntax
Very loosely coupled interface
Viewrpt.csp (Crystal Server Page)
URL Parts:
uri
apsuser, apspassword, apsauthtype
Init
promptex
cmd
COMP-12 Integrating Crystal and Your OpenEdge Application

23. Example URL’s – View and Refresh
viewrpt.csp?uri=crystal/sample_simple &apsuser=administrator&apspassword= Pr0gr3$$&apsauthtype=secEnterprise &cmd=export&export_fmt=u2fpdf:0
<same as previous, except last line> &promptex-empStart=10&promptex-MijnParam=My own report header &init=actx:connect
COMP-12 Integrating Crystal and Your OpenEdge Application

24. COMP-12 Integrating Crystal and Your OpenEdge Application

25. COMP-12 Integrating Crystal and Your OpenEdge Application

26. Conclusion Data access ODBC for easiest ad-hoc and other cases
Many options exist – which to choose?
Data access
ODBC for easiest ad-hoc and other cases
XML or Open Client Java Bean / ADO.NET for best re-use of business logic
Integration
Use CR Server if possible – grow path to Business Objects Enterprise
ActiveX or DHTML/Browser to view
COMP-12 Integrating Crystal and Your OpenEdge Application

27. Questions?
COMP-12 Integrating Crystal and Your OpenEdge Application

28. Thank you for your time!
COMP-12 Integrating Crystal and Your OpenEdge Application

29. COMP-12 Integrating Crystal and Your OpenEdge Application