Additional Result object processing

  • Roman Muntyanu

    Roman Muntyanu - 2006-01-10


    I'm working on Driving Regulations Report system. It includes a number of business constraints. We have decided to use JPivot/Mondrian for reporting.
    The rules are quite complex, so I'm unable to implement them in SQL or JPivot/Mondrian's 'IIF' conditions, because constraints concearn different levels of aggregation (like totals per week and per month). Plus these constraints may change it would still be hard to trace them if they are not in one standard class.

    The conclusion here is that I require additional business layer, that will intercept JPivot or Mondrian Result object
    - analyze it;
    - change it accordingly to business rules;
    - pass this object forward as if it was the actual result from Mondrian/JPivot;

    And thus the questions:
    - Is it possible in current implementation of JPivot (whithout changes to JPivot code)?
    - What should be done to achieve the goal otherwise?
    Thank you.


    • Sherman Wood

      Sherman Wood - 2006-01-10

      Maybe you need to refine your dimensional model to more closely match your business contraints.

      Can you give examples of your business rules/constraints, such as the selection criteria and the types of transformations you want to do?


    • Roman Muntyanu

      Roman Muntyanu - 2006-01-10

      Here is the example of the business constraints (also called Basic regulations):
      • The average working time per week is maximized to 48 hours. This average is calculated over a reference period of 4 till 6 months.
      • The maximum working time per week is 60 hours.
      • The maximum working time per shift is 12 hours
      • When the shift length is between 6 and 9 hours there should be a break time of at least 30 minutes.
      • When the shift length is grater dan 9 hours there should be a break time of at least 45 minutes.
      • A nightshift starts at 0:00 hour and ends at 6:00 hour.
      • When working during the nightshift time the maximum shiftlength (a shift is an activity time between 2 rests of at least 8 hours each) in a period of 24 hours is 10 hours.

      Of-course all of the numeric values vary from one system user to other. If one company has 10 hour night shift constrain - the other may want to have 9 hour night shift constraint. These specific values are taken from the database.

      And errors to be reported:
      • Working Time: When the working time exceeds the maximum working time per week an error should be shown (When working time is greater than 60 hours per week).
      • Resting / Break error: Based on the length of a shift the driver should take breaks. When the driver doesn’t take a break or when the total break time is too short an error should be shown.
      • Shift error: A shift may have a maximum length. When the driver exceeds the shift length an error should be shown.
      • Night work: When night work is executed the shift length differs from the normal shift length. In this situation also an error should be shown.

      'Reported' means highlighted in the totals report if some error occurs.
      The information is selected into a per-driver report within a given time interval.

      What I want to do is pass the Result object to a class that implements these constraints. Based on the constraints this class will analyze each row in the Result object (distinguishing the aggregation level using 'level' property of axes' properties like result.getAxes()[0].positions[0].getMembers()[0].getLevel()). If an error situation is recovered an appropriate additional property or measure will be (re)written (is what I understand under 'transformations').
      Finally in my MDX/Schema I will analyze these additional properties and highlight the fault rows.

      Hope I've described everythig clear enough. If you need aditional explanation just ask.

      Thanks for the support :)


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks