..custom report/parameter pages in LBI 9..

Sort:
You are not authorized to post a reply.
Author
Messages
Jesse
Basic Member
Posts: 10
Basic Member
    We are currently upgrading our LRS environment from LRS to LBI 9. Our LRS environment was on Windows 2000 with Tomcat as the HTTPd. Our LBI environment is on Windows 2003 with WebSphere as the HTTPd. In LRS we used custom report pages to provide a user with parameters that are then fed into Crystal reports upon run-time. The custom page was a .JSP that would call a SQL Server DB residing on the same box as LRS to query for parameters. The user would then click submit, and the report ran with the parameters that the user specified.

    Enter LBI 9 - we cannot get the same process to work. We are unsure whether we are not making the correct call to the SQL Server, or whether it should be different, since we are now on WebSphere as opposed to Tomcat. Below is a snipet of a sample .JSP that works on LRS, but not on LBI 9:

    <%@ page import="java.sql.Connection,
    java.sql.DriverManager,
    java.sql.Statement"%>
    <%
    String strScreenHeader="Labor Distribution by Pay Period";

    //*******************************************
    //DEFINE ONCE FOR EACH SERVER CONNECTION TYPE
    //*******************************************
    //For SQL Server
    Class.forName("com.microsoft.jdbc.sqlserver.SQLServerDriver");
    Connection cnn = DriverManager.getConnection("jdbc:microsoft:sqlserver://localhost;User=report;Password=123456;DatabaseName=LawsonVTS");

    Statement stmt = cnn.createStatement();
    //*************************************

    //**********************************************************************
    //DEFINE A Separate one for each Dynamic Value if the come from different Queries.
    //**********************************************************************
    java.sql.ResultSet rs1;
    String SQLQuery1 = "Select Company as Filter from VTS_RptDist where UserID = '" + request.getParameter("fsuserid") + "' and Suite = 'FN' and Role = 'ALL'";

    By the way, the purpose of us needing this, is that our user-level access to companies/acct-units is controlled by this parameter page. It determines the username upon run-time, and then queries only the companies/acct-units that the user is authorized to view.

    In LBI 9, after publishing the report we used the Events section to define a Parameter Selection event. We entered the web path of where the JSP resides, and saved.

    Upon running the report, instead of getting the parameter page, we get:

    Error 500: com.microsoft.jdbc.sqlserver.SQLServerDriver

    Has anyone come across this, or have any ideas as to how we can get this working? Thanks for looking!
    John Henley
    Senior Member
    Posts: 3349
    Senior Member
      Start by checking two things:
      1. Make sure the driver JARs for MS SQL server are in the classpath
      2. Double-check your websphere administration setup correctly for SQL server connections.

      BTW, rather than having your own security layer, you can do that from LBI....where parameters can be 'hooked' via the Lawson OLEDB provider to use Lawson security. You could use that to filter against GLSYSTEM/GLNAMES, etc. to filter out the parameter list to only include the companies / accounting units to which a user has access.
      Thanks for using the LawsonGuru.com forums!
      John
      Jesse
      Basic Member
      Posts: 10
      Basic Member
        Thanks for the suggestion regarding the classpath, John! We are looking into that now - you were correct in that I don't see anything there related to the JAR's. I will respond shortly with the outcome...

        Regarding security, the reason we are using these custom JSP's is that our reports are built to run directly against the Oracle production DB (for performance reasons.) Unfortunately, limited security options necessitate having one userid/password in Oracle that is used by all the reports. However, we still want user-level security access based on company/acct-unit. To make this work, we have written all our Crystal reports using custom SQL queries. In the WHERE clause of these queries, it says, for example...

        WHERE employee.process_level in ({?Company})
        and employee.department in ({?Acct-Unit})

        Crystal then interprets the {?variable} as a parameter and allow the user to feed in data upon run-time. At this point, when the user clicks on a report, in LRS it would actually run the JSP first, which would query a separate SQL Server for the companies/acct-units that the user is allowed to access, and pre-populate the company and acct-unit fields with these values. The fields would then be locked so that the user could view, but not edit them. At this point, the user would see something like:

        Company: 2301,2302,2303
        Acct-Unit: 1000,1001,1002,1003,1004

        After the user hits submit, the pre-populated parameters are passed to the Crystal engine, which then executes the query against Oracle and returns the results back to Crystal, displaying the report.

        I am not clear about how we can "hook" these parameters up to OLEDB, as the format of WHERE process_level in ({?Company}) requires a comma separated string. Not meaning to get off topic from the original post, but any ideas on how this process might be made more efficient? Thanks again!
        John Henley
        Senior Member
        Posts: 3349
        Senior Member
          You would continue to run the reports against the Oracle database. The difference is that data source for the parameters would no longer be your custom security database, but would be Lawson tables, accessed via Lawson's OLEDB provider. This would allow you to limit the parameter list to the values to which your users have access because the OLEDB provider would filter out based on LAUA security. You could do that with LBI and eliminate your custom JSP pages.

          On a different note, I'm curious -- why are you using LBI / LRS at all ? The method for your reporting method doesn't use any Lawson features--you are just using Crystal.
          Thanks for using the LawsonGuru.com forums!
          John
          Jesse
          Basic Member
          Posts: 10
          Basic Member
            We are using LRS/LBI to take advantage of a consistent interface look-and-feel for end users and the ability for users to run Crystal reports without having the Crystal client installed.
            You are not authorized to post a reply.