SDK and Session Caching

[txknight]

Hi all,

I've never had cause to learn to use the Crystal SDK or even make changes (for the most part), to the Crystal CSP pages. However it seems as though this is about to change. In particular, my supervisor has asked me to add some functionality to CE10. With that in mind, I was wondering if any of folks can point me in the right direction. What language would be best to use? Can I make simple changes to the CSP pages or will I need to do some API calls? I haven't programmed in years, so I need to some help getting started.

In case you curios, I have been asked to make Crystal cache any database logon information (id & password) for a users in a given session. If you've seen my most recent post, you know what I'm trying to do. But in short, I'm trying to add database Single Sign-On to CE10. My supervisor suggested using cookies, but I'm open for anything.

For reference, we use a variety of databases. However our primary one, and the one that is immediately relevant to this problem is Oracle 8i. To access our Oracle 8i databases, we typically use System DSNs with Data Direct's ODBC drivers. Also, we run CE10 in a clustered environment with Microsoft Server. IIS is our web server.

BTW, I know there are better ways of doing this (as opposed to making codeing changes to CE10). For example, I know BOE XI has this capability. However this thread isn't for those ideas. Please feel free to share those ideas, but I would ask that you find my other thread (which is releatively recent), and post your ideas to that one.

Thanks in advance for any assistance,
TX Knight ;-)

 

[Turkbear]

Hi,
Database logon info 'travels' with the report when it is published to the CE system ( assuming you tell it to)..That way, the data is secured with a username/password that only the CE administrator and the Report Designers can see ( as well as the DBA).

Why is this not the way to go for your situation?







To Paraphrase:"The Help you get is proportional to the Help you give.."

 

[txknight]

Hi Turkbear,

Not all information travels with the report when it is published. And even some of that tends to be removed due to agency protocol. In particular, when a report gets published, I as the adminsitrator typically has to make sure that the default database login id is empty. That way, whenever a user schedules a report, he has to always fill in the database logon id and password.

The problem here is that our users, during any given session on CE10, only want to have to type there database user id and password once. After that, they want CE10 to remember it. Hence why I'm trying to create some sort of session cache. And also why I need help getting started. There is a pelthora of information out there and I'm trying as much as possible to avoid going down the wrong path. I'm hoping someone on these forums has done something like this before and can lead me in the right direction.

Thanks,
TX Knight ;-)

 

[Turkbear]

Hi,
Just very curious:
Why this?

In particular, when a report gets published, I as the adminsitrator typically has to make sure that the default database login id is empty. That way, whenever a user schedules a report, he has to always fill in the database logon id and password.

Seems like you are avoiding one of the better features of publishing and one that is more secure than using session objects..
( By schedule do you mean 'view on demand' or actually 'schedule for later'?)




To Paraphrase:"The Help you get is proportional to the Help you give.."

 

[txknight]

It's possible we are missing out on a lot of features of the publishing utility. Especially since we don't use it!

Typically what happens is that a developer will develop and save a report directly to our CE10 Test cluster using CR 10. When they are done and happy with their report, we will use Import Wizard to move the report from the test cluster to the production cluster. There we tidy it up (make sure all defaults are set to the customers likeing) and test it.

And I'm not sure in this case where there will be a difference in how 'View On Demand' works and 'Schedule For Later'. Since we don't save a user id or password as a default value in the database tab of the report setup in the CMC, the user will have to fill the values in when either option is chosen.

But if I need to make a distinction, I'd say most of users use the 'Schedule for Later' feature.

Thanks,
TX Knight ;-)

 

[txknight]

Just very curious:
Why this?

Almost forgot. Why do we remove the user id and password from the report in the Enterprise system? Because of the DBAs want accountability. In other words, if a user decideds to run a 100 reports suddenly, which translates to a 100+ SQLs on there side, they want to see who did it. Not just some generic name that is used for all Crystal Reports.

 

[Turkbear]

Hi,

'Schedule for Later' requires a default username/password since it is run without user interaction.


You can Audit who runs the reports with CE10's auditing feature.








To Paraphrase:"The Help you get is proportional to the Help you give.."