Enhance the "parameter entry" screen of a crystal report in infoview

[former_member221754]

Is there a method to enhance the "parameter entry" screen of a crystal report when executed through infoview/cmc?

(background - migrating reports from bi portal to bobj / infoview)

1 - A report is created in crystal based off of a BeX query.

2 - The .rpt is published

3 - Navigate to report in infoview / cmc

4 - Selection screen, or "parameter entry" fields are displayed.

5 - Enter values in the "new value" field, and then we see the "current value" field.

Our users are resistant and asking if this can be altered. We are pushing back, but I wanted to check with experts first. I'm posting this in general, b/c I'm not sure where this task might be accomplished.

We currently have the bi portal, and consider it more user friendly. I base this on our users feeling it's more intuitive, and also there are less "clicks" to enter the desired data. I also have not seen the ability to save variants, or report entry criteria through infoview, or the "check" values button.

Is this just a limitation we live with?

Can visual studio be leverage in any way?

Can WebElements be used?

Thanks,

MB

[former_member142702 · Accepted solution]

Hi

an option is to publish your CR reports in your BO repository with stored (empty) data and train your users to use the parameters panel in the Viewer window. Hopefully your users consider this panel more user friendly.

Which viewer do you use for your crystal reports? HTML, Java or ActiveX?

For sure you can build your own viewer using the BOE SDK.

Regards,

Stratos

[former_member221754 · Accepted solution]

Which viewer do you use for your crystal reports? HTML, Java or ActiveX?

Java

For sure you can build your own viewer using the BOE SDK.

Have you / or anyone done this? Would we still have the inherited SAP security we get now in infoview/cmc? (ex. user clicks on profit center hierarchy parameter button and can only select profit centers they have access to).

Pros/Cons for this method? I'm still somewhat new to BOBJ so appreciate as much info as possible.

Thanks for the quick response Stratos.

[former_member142702 · Accepted solution]

The SAP security is applied during the datsa retrieval. So you do not have to reimplement it.

I have already been messing around with the Javascript files on the BOBJ server in order to modify the behaviour of the parameter panel. In my case I was using the HTML viewer. Still I am not sure what exactly the functionality is your users would like to have. You may want to talk to SAP consulting about this in order to get a realistic estimation on the scope and the overhead of such a modification.

Regards,

Stratos

[former_member221754 · Accepted solution]

The existing parameter entry screens are confusing users b/c of the interaction b/t the "new value" text box for each parameter, verse current value.

The current value, b/c it exists in text only below the input box, does not give the impression that they have entered data.

Today in portal, they enter it in one box, and it stays there, then they execute. Going forward, it seems like you have to type in ... say 5 variables, and hit "add" for each one. That isn't intuitive and feels like a step back from existing functionality.

ideally, they could enter, the values in bold, into the text box, then not hit the "add" button, and then click "execute".

fiscal year = 2009

posting period = 10

controlling area = 1000

profit center = 1234

currency = usd

As it stands in our sessions today, I'm having to tell them to either find where they are in the hierarchy, or enter the value and hit the "add" button for each parameter.

So, basically wondering if anyone else has encountered this, b/c it seems like it would be a common issue, and there would be a more "standard" way to modify the behavior of these screens.

I logged OSS note, but quickly received the obligatory phone call saying, "don't do it, we don't support it, can I please close the note."

[JWiseman · Accepted solution]

hi Matt,

you could use webelements to create a custom prompt / parameter page.

the end user would not see the default prompt dialogue again. this would be the same as creating your own custom prompt page with web controls that populate an opendocument url.

you can either embed the controls on the report you have already or create a new report that would act as the prompt page.

a) if you create a new report to act as the prompt page, then you give users access to that new report instead of the report you have already.

b) if you embed controls on your existing report, you give users access to a default opendocument hyperlink instead of the report itself. this way they do not see the prompt dialogue when first opening the report as the hyperlink will bring the report up with default values. any changes using the embedded controls would bypass the prompt dialogue.

cheers,

jamie

[former_member221754 · Accepted solution]

Thanks Jamie.

I believe that's the route I will explore to start with. Do you know of any documentation exists on the net as a solid starting point? I downloaded WebElements 2.45 Custom Function Library and will begin tinkering with the controls today, I also see some documentation within that download.

-MB

[JWiseman · Accepted solution]

hey Matt,

there is a user guide in the download as a reference to what each function does.

at the beginning of this guide there are a couple of examples to help you get the concept of using the control sets. so follow the installation instructions first and then the brief "how to" should be helpful. webelements are crystal reports custom functions, so if you use the formula editor you will be familiar with functions in crystal reports.

once you being your new prompt page, the main webelements report also has the vast majority of the custom functions filled out in existing formulae on the report...so you can just copy and paste these onto your new report and edit as appropriate.

one tip is to use the "weviewer" function to hide the toolbar on the prompt page report for aesthetic reasons.

another tip is to hard code the control values into the functions if these are values that never or rarely change...easier setup versus using live data.

there are a bunch of sample reports, that show all of the controls, that you can publish to your enterprise system after you've configured pass through html as per the user guide.

cheers,

jamie

[former_member221754 · Accepted solution]

Jamie -

I'm making progress with WebElements.

So far...

-Installed

-Enabled HTML pass through (somewhat different path b/c we are Linux, but found it)

-Created prompt page with input box and submit button

Now, I'm trying to capture the value from the input box, and pass it to the next report. We are on Linux and I don't see that as an option in the "WEPlatform" function.

Would that fall into the category of other, and does that mean I should hard code the path to the "opendocument.<ext>" page?

The problem now is when I click the submit, it's navigating to a folder structure that does not exist.

Liking WE so far, thanks.

mb

[JWiseman · Accepted solution]

hey Matt,

glad that you like using them thus far.

can you do me a huge favour and repost this in a new forum post?...that way other linux / cr users can more readily find the problem - solution if need be.

when you post a question to the forums and you are using webelements, just make sure that the subject has "webelements" or "web elements" in it so that our team can find it quickly.

make sure that you state the version of BOE, or cr server and the OS platform that you are using too.

in the meantime i will try to find an answer for you...i was not aware that opendocument had a different relative path than on windows servers but that's mostly because it was something that i never tested first hand.

cheers,

jamie