2008 Jul 17 4:54 PM
Hi All,
I've come across a requirement that needs to build a report.
However, the set of definitions defined for the report output might change over time.
Now every time the Definitions change, the User might have to request the change in the report through a development.
Is there a way, where the Users can maintain certain set of rules and which can be maintained easily, but also allow the report to dynamically pick up the logic that it needs to process the data to the required output layout.
To explain a little more in detail;
Data from ZTABLEA is reported out by issuing each line with a BucketID.
The report will aggregate the data to each Bucket Levels in output.
But, The Logic for issuing the ZTABLEA line with a BucketID can change over time.
So, a ZTABLEA line which was issued a BucketID_1 initially when FIELD1 of ZTABLEA = A,
can later be assigned to another BucketID when FIELD1 of ZTABLEA = A.
And this assignment needs to be maintained by the Users.
Some of these Logics can be complex in the sense that they Could span over several Fields for a condition.
Please advice. Any and all suggestions are highly appreciated.
Thanks,
RK.
Edited by: RK on Jul 17, 2008 7:16 PM
2008 Jul 18 9:32 AM
Sorry you lost me at the buckets But if the assignments logic is complicated then one way of doing this could be creating a new Z table to store your dynamic assignments. Then create a Z program/transaction for the users that will allow them to maintain assignments in that table. That way your report will not have to be limited to hard-coded rules, and can use the assignment rules from the Z table. It would all have to be robust enough to cope with user error however...
Hi All,
I've come across a requirement that needs to build a report.
However, the set of definitions defined for the report output might change over time.
Now every time the Definitions change, the User might have to request the change in the report through a development.
Is there a way, where the Users can maintain certain set of rules and which can be maintained easily, but also allow the report to dynamically pick up the logic that it needs to process the data to the required output layout.
To explain a little more in detail;
Data from ZTABLEA is reported out by issuing each line with a BucketID.
The report will aggregate the data to each Bucket Levels in output.
But, The Logic for issuing the ZTABLEA line with a BucketID can change over time.
So, a ZTABLEA line which was issued a BucketID_1 initially when FIELD1 of ZTABLEA = A,
can later be assigned to another BucketID when FIELD1 of ZTABLEA = A.
And this assignment needs to be maintained by the Users.
Some of these Logics can be complex in the sense that they Could span over several Fields for a condition.
Please advice. Any and all suggestions are highly appreciated.
Thanks,
RK.
Edited by: RK on Jul 17, 2008 7:16 PM
2008 Jul 18 9:32 AM
Sorry you lost me at the buckets But if the assignments logic is complicated then one way of doing this could be creating a new Z table to store your dynamic assignments. Then create a Z program/transaction for the users that will allow them to maintain assignments in that table. That way your report will not have to be limited to hard-coded rules, and can use the assignment rules from the Z table. It would all have to be robust enough to cope with user error however...
2008 Jul 18 9:46 AM
Following in from what Kev said.
There's dynamic SQL available (which you should put in a TRY...CATCH....ENDTRY block), so they can effectively define a WHERE condition, which would be stored in your table.
I'd suggest that you have a check when they save the new logic, that the where clause is valid.
If you need some kind of other dynamic abap look at GENERATE, READ REPORT and other associated keywords in the ABAP help.
matt
2008 Jul 18 12:28 PM
Thanks Kev.
I am hoping to proceed as you have suggested. Allowing the users to maintain a Z-Table with assignments logic .
I also found a similar solution that is used by the GOLD Client (TCode: ZGOLD) where they allow to maintain SQL Scenarios. And the SQL Statements are developed dynamically using those rules from tables at runtime.
Thanks again for the advice.
RK.
2008 Jul 18 12:34 PM
Thanks Matt,
I will have to follow your advice when i'm building my dynamic SQL statements by using the TRY...CATCH....ENDTRY block. Also checking the assignments when the user saves the new logic is a challenge, but you make a very good point and i agree it is the best place to validate. And its good to know that i have other options where i can generate a whole new dynamic report.
Thanks again for your help.
RK.
2008 Jul 18 7:56 PM