I am looking for a solution where I could generate a rule log and make it available on client side. I know generating a log during consolidation and save it on server. However, I want to make it available on client side.
I have created four scenarios in HFM application, namely -
1. ACTUAL_REPORTING - To capture TB data and use it for reporting
2. ACTUAL_ICP - To capture ICP data and run custom business rule as per requirement
3. ACTUAL_ADDINPUT - To capture additional memorandum inputs
During consolidation,data is copied from ACTUAL_ICP and ACTUAL_ADDINPUT to ACTUAL_REPORTING. However, problem is that user should consolidate ACTUAL_ICP AND ACTUAL_ADDINPUT scenarios first. If they miss executing the consolidation in these scenarios, then the data copied would be wrong. Just as to ensure this, there's a provision is HFM to check calculation status in rule file and looking at that, calcuation could be stopped and a message could be sent to the user. But delimma is, how to report the same on the user side.
Possible solution that I could have thought are -
1. To generate a rule log and post the same to the client, but how to do this? As path of the rule log could be of the server only (that is C:\Hyperion\Logs\Rule)
2. To generate a rule log and pop a web page terminating consolidation, but how to do this?
3. To raise an error from the rule file and direct it to the system messages, but how to to this?
Please advice and any further clarification is required please contact me.
You can define the output folder as a share, which has already been mentioned. I strongly advise against implementing any solution that in production will regularly generate an external file.
1) The output file is generated by the DCOM user. If you want this user to generate a file in a specific location, it must be writeable by the DCOM user, and readable by the intended human user. Make sure both NTFS and share level permissions on the target file and its containing folder consider this. Latency for the file write can degrade performance.
2) Most HFM implementations have two or more HFM application servers. You have no control over which server will execute the file, and also no control over what happens if two or more servers try to write to the same file. You can create a process which causes HFM to become single threaded if every time Sub Calculate for any entity on any server needs to open a single file. This is because the file object is single threaded. It could be multi-threaded if you write out to a database, but certainly far more complex.
3) Wait state: while as in #2, this can single thread the process, and you have to consider whether your process will error out during moments when another process has access to the file, or if you will ignore that and simply proceed. This can have a significant impact on performance time if you decide to wait until the file becomes available.
While I have done implementations where the overall solution required combining data across multiple scenarios, I consistently find this a cumbersome, error-prone, and poorly performing approach. For this reason, I always try to keep all of the data required in a single scenario. This is one key reason why the "DataSource" or "DataType" (or whatever you call it) approach is so popular and successful.
Finally, you cannot write to the HFM system messages. You can, on the other hand, use Calc Manager to write out to a system log.