Topic
  • 3 replies
  • Latest Post - ‏2013-10-28T13:02:30Z by Kareem Naguib
Kareem Naguib
Kareem Naguib
65 Posts

Pinned topic How to add non-persistent field to Reporting object structure?

‏2013-10-27T14:19:30Z |

Hello Professionals, 

 

We have Maximo Asset Management 7.5,

our customer asked for a QBR for PM Details, PM Reporting Object Structure is not available by default, so we created it with only one object "PM",

Customer want to show Earliest Next Due Date field in the QBR, this field is non-persistent, after including it in the object structure and generate schema,

field is still not appear in the QBR,

 

How can i add a non-persistent field to Reporting Object Structure?

Thanks in Advance,

 

 

  • SASHULL
    SASHULL
    302 Posts
    ACCEPTED ANSWER

    Re: How to add non-persistent field to Reporting object structure?

    ‏2013-10-28T12:53:04Z  

    Simple answer, you can't.

    Extended answer: Just like if you made your own custom report, BIRT connects directly to the database and runs a query. The reason you can't is because a non-persistent is a calculated field or a field that doesn't exist on the table you are dealing with and so the database doesn't even know about the field, thus it can't display the value. You can in some instances (like a long description) join to the other table where it's stored and display it that way because the other table has that field persistently. In other cases, you can decide to replicate the calculation directly in your BIRT report if the calculation isn't too complicated.

    In this case, Earliest Next Due Date is a pretty complicated calculation as it takes into account seasonal dates, frequency, extended dates, etc. In cases where the next time it should be generated was in the past, the Earliest Next Due Date would use the current date. Trying to build out this logic would be very tough inside a report though technically not impossible.

    An alternative, that isn't perfect, is on the PM table there is a NEXTDATE field which is persistent and displays the next date it would generate if things like seasonal dates don't apply. Some of our clients don't take advantage of seasonal dates/extended dates so displaying the NEXTDATE works just as well but it would be something you need to consider.

  • SASHULL
    SASHULL
    302 Posts

    Re: How to add non-persistent field to Reporting object structure?

    ‏2013-10-28T12:53:04Z  

    Simple answer, you can't.

    Extended answer: Just like if you made your own custom report, BIRT connects directly to the database and runs a query. The reason you can't is because a non-persistent is a calculated field or a field that doesn't exist on the table you are dealing with and so the database doesn't even know about the field, thus it can't display the value. You can in some instances (like a long description) join to the other table where it's stored and display it that way because the other table has that field persistently. In other cases, you can decide to replicate the calculation directly in your BIRT report if the calculation isn't too complicated.

    In this case, Earliest Next Due Date is a pretty complicated calculation as it takes into account seasonal dates, frequency, extended dates, etc. In cases where the next time it should be generated was in the past, the Earliest Next Due Date would use the current date. Trying to build out this logic would be very tough inside a report though technically not impossible.

    An alternative, that isn't perfect, is on the PM table there is a NEXTDATE field which is persistent and displays the next date it would generate if things like seasonal dates don't apply. Some of our clients don't take advantage of seasonal dates/extended dates so displaying the NEXTDATE works just as well but it would be something you need to consider.

  • Kareem Naguib
    Kareem Naguib
    65 Posts

    Re: How to add non-persistent field to Reporting object structure?

    ‏2013-10-28T12:58:29Z  
    • SASHULL
    • ‏2013-10-28T12:53:04Z

    Simple answer, you can't.

    Extended answer: Just like if you made your own custom report, BIRT connects directly to the database and runs a query. The reason you can't is because a non-persistent is a calculated field or a field that doesn't exist on the table you are dealing with and so the database doesn't even know about the field, thus it can't display the value. You can in some instances (like a long description) join to the other table where it's stored and display it that way because the other table has that field persistently. In other cases, you can decide to replicate the calculation directly in your BIRT report if the calculation isn't too complicated.

    In this case, Earliest Next Due Date is a pretty complicated calculation as it takes into account seasonal dates, frequency, extended dates, etc. In cases where the next time it should be generated was in the past, the Earliest Next Due Date would use the current date. Trying to build out this logic would be very tough inside a report though technically not impossible.

    An alternative, that isn't perfect, is on the PM table there is a NEXTDATE field which is persistent and displays the next date it would generate if things like seasonal dates don't apply. Some of our clients don't take advantage of seasonal dates/extended dates so displaying the NEXTDATE works just as well but it would be something you need to consider.

    SASHULL, 

    as usual, your answer is complete, clear, simple 

    Thank you very much 

  • Kareem Naguib
    Kareem Naguib
    65 Posts

    Re: How to add non-persistent field to Reporting object structure?

    ‏2013-10-28T13:02:30Z  
    • SASHULL
    • ‏2013-10-28T12:53:04Z

    Simple answer, you can't.

    Extended answer: Just like if you made your own custom report, BIRT connects directly to the database and runs a query. The reason you can't is because a non-persistent is a calculated field or a field that doesn't exist on the table you are dealing with and so the database doesn't even know about the field, thus it can't display the value. You can in some instances (like a long description) join to the other table where it's stored and display it that way because the other table has that field persistently. In other cases, you can decide to replicate the calculation directly in your BIRT report if the calculation isn't too complicated.

    In this case, Earliest Next Due Date is a pretty complicated calculation as it takes into account seasonal dates, frequency, extended dates, etc. In cases where the next time it should be generated was in the past, the Earliest Next Due Date would use the current date. Trying to build out this logic would be very tough inside a report though technically not impossible.

    An alternative, that isn't perfect, is on the PM table there is a NEXTDATE field which is persistent and displays the next date it would generate if things like seasonal dates don't apply. Some of our clients don't take advantage of seasonal dates/extended dates so displaying the NEXTDATE works just as well but it would be something you need to consider.

    However, i'm trying to make a work around to this issue, i have created an action script to copy the Earliest next due date value to another persistent field, and it is working fine, but the value is only display in the application, it doesn't save the value to database, 

    until, i change anything to the record then press save, and it is now save the value,

    Is this scenario valid?

    what is your opinion?