tm1s-log.properties for Process Parameters

[paulsimon]

Hi

Does anyone know the tm1s-log.properties line that is needed to make the TM1Server.log show the parameters that were passed to a process as well as the name of the process, as it does by default?

Presumably it is something along the lines of

log4j.logger.TM1.Process.

but what goes after this?

I am looking to get something like

5216 [5] INFO 2015-11-20 16:02:01.470 TM1.Process Process "zTD_Attr_Export_to_backup_file_Param_Dim" executed by user "Paul Simon"

EXTRA PART Parameter pDim was Cost_Centre

Regards

Paul Simon

[qml]

Someone correct me if I'm wrong, but there doesn't seem to be a logger for TI process parameters. I would expect log4j.logger.TM1.Process to offer the appropriate child logger (log4j.logger.TM1.Process.Parameters) but it doesn't. You can log things like e.g. TI function parameters (log4j.logger.TM1.Process.Functions.Parameters) but, weirdly, not TI process parameters.

[lotsaram]

I have always done this passing the parameter values into a process logging cube, but this does require the discipline to insert the code for each process.

[gtonkin]

I cannot see a useful option either for TI process parameters. What I did seem to find is the following list - based on my 10.2.2 FP4 server - no guarantees/warranties etc. etc. on using any of these.

Code: Select all

TM1.HttpResponseBody
TM1.HttpResponseHeaders
TM1.HttpResponse
TM1.HttpRequestBody
TM1.HttpRequestHeaders
TM1.HttpRequest
TM1.HttpSession
TM1.Transaction
TM1.Process
TM1.SQLAPI
TM1.Sip
TM1.Server
TM1.Dimension
TM1.Cubeload
TM1.Cube.Drill
TM1.Cube
TM1.Connection
TM1.Chore
TM1.Client
TM1.Catalog
TM1
TM1.API
TM1.API.Parameters
TM1.API.Return
TM1.API.Return.Error
TM1.API.Return.Object
TM1.API.Return.String
TM1.API.Retry
TM1.APIDetail
TM1.APIDetail.Parameters
TM1.APIDetail.Parameters.ExpandArray
TM1.APIDetail.Return
TM1.APIDetail.Return.Array
TM1.APIDetail.Return.Array.Cube
TM1.APIDetail.Return.Array.Dimension
TM1.APIDetail.Return.Array.Subset
TM1.APIDetail.Return.Array.View
TM1.APIDetail.Return.Bool
TM1.APIDetail.Return.Index
TM1.APIDetail.Return.Real
TM1.LoginAPI
TM1.LoginAPI.Parameters
TM1.LoginAPI.Return
TM1.LoginAPI.Return.Error
TM1.LoginAPI.Return.Object
TM1.LoginAPI.Return.String
TM1.LoginAPI.Retry
TM1.LoginAPIDetail
TM1.LoginAPIDetail.Parameters
TM1.LoginAPIDetail.Parameters.ExpandArray
TM1.LoginAPIDetail.Return
TM1.LoginAPIDetail.Return.Array
TM1.LoginAPIDetail.Return.Bool
TM1.LoginAPIDetail.Return.Index
TM1.LoginAPIDetail.Return.Real
TM1.Audit
TM1.Audit.PostProcessor
TM1.Audit.Query
TM1.Audit.ResultSet
TM1.Audit.Reader
TM1.Application
TM1.Base
TM1.Base.GetImpl
TM1.Blob
TM1.Client.Detail
TM1.Security
TM1.CAMSecurity
TM1.ColIterator
TM1.Comm
TM1.Comm.SSL
TM1.Commit
TM1.Commit.Data
TM1.Connection.RSData
TM1.CRYPT
TM1.Cube.CalculationCache
TM1.Cube.CalculationCache.Cell
TM1.Cube.Commit
TM1.Cube.Iterator
TM1.Cube.Invalidation
TM1.Cube.ThreadCalculation
TM1.Cube.Batch
TM1.Cube.Dependency
TM1.Cube.VersionedTree
TM1.Cube.VersionedTree.References
TM1.Cube.VersionedTree.Versions
TM1.Cube.Spreading
TM1.Cube.Stargate
TM1.Cube.Stargate.Catalog
TM1.Cube.Stargate.Definition
TM1.Cube.Stargate.Reference
TM1.Cube.Stargate.ViewStorage
TM1.Cube.Subscription
TM1.Cube.Picklist
TM1.DataSource
TM1.DataSource.CubeView
TM1.DataReservation
TM1.Dimension.Element
TM1.Dimension.ElementPool
TM1.Dimension.PseudoEle
TM1.Element
TM1.Event
TM1.File
TM1.Folder
TM1.Group
TM1.GlobalCollection
TM1.GlobalObjectCache
TM1.ObjectRegistry
TM1.HierarchyLevel
TM1.Lock
TM1.Lock.Exception
TM1.Lock.CriticalSection
TM1.Lock.SYSMT
TM1.CheckLockHeld
TM1.MetaLogger
TM1.Object
TM1.ODBC
TM1.Odbo
TM1.OdboRowset
TM1.Query
TM1.Registration
TM1.Rowset
TM1.Rule
TM1.Rule.Analysis
TM1.Rule.Analysis.Details
TM1.Rule.ElementAliases
TM1.Rule.Evaluation
TM1.Sap
TM1.SaveDataAll
TM1.Cognos
TM1.Sandbox
TM1.Sandbox.Merge
TM1.Sandbox.Merge.Parameters
TM1.Sandbox.Merge.Queue.Request
TM1.Server.Config
TM1.Server.Config.Registry
TM1.Server.Distributed
TM1.Server.Memory
TM1.Server.Memory.MemBytes
TM1.Server.Memory.PoolCount
TM1.Server.Memory.PoolBytes
TM1.Server.Memory.Debug
TM1.Server.NB.PacketReader
TM1.Server.NB.FunctionReader
TM1.Server.NB.UserSession
TM1.Server.NB.Reactor
TM1.Server.NB.ResponsePacker
TM1.Server.NB.Acceptor
TM1.Server.NB.ThreadPool
TM1.Server.NB.TM1SessionIOMonitor
TM1.Server.Network
TM1.Server.Network.Detail
TM1.Server.Network.APIPack
TM1.Server.Network.APIUnpack
TM1.Server.Threads
TM1.Set
TM1.Sql
TM1.StatsMonitor
TM1.System
TM1.System.File
TM1.SSPI
TM1.Subset
TM1.View
TM1.Hierarchy
TM1.LDAPAuth
TM1.Mdx
TM1.Mdx.Interface
TM1.ServerGroupMap
TM1.UI
TM1.SSPISecurity
TM1.Process.Functions
TM1.Process.Functions.Parameters
TM1.OldQuery
TM1.MdxViewCreate
TM1.ClientMessage
TM1.ObjectIndex
TM1.OdboSchema
TM1.OdboSchema.MembersRowset
TM1.OdboSchema.MeasuresRowset
TM1.Updates
TM1.ViewArray
TM1.NGAPI
TM1.NGAPI.REST
TM1.NGAPI.FACET
TM1.Parallel
TM1.Parallel.SplitPlan
TM1.Parallel.Splits
TM1.Parallel.Operation
TM1.OperationThread
TM1.ConnectionRequestThread
TM1.TILogOutput
TM1Diag.CheckLockHeld
TM1Diag.TIDebugUtility
TM1_AR
TM1_AR.API
TM1_AR.API.Error
TM1_AR.API.Parameters
TM1_AR.API.Parameters.ExpandArray
TM1_AR.API.Return
TM1_AR.API.Return.ExpandArray
TM1_AR.Server.Network.Detail
TM1.Login
TM1.TM1Top

Adding the TM1.System.File=DEBUG for example is quite useful if you are trying to track which files are being written to and possibly being interfered with by AV.
TM1.Server.Network is useful if you are trying to ascertain how "chatty" the traffic is.

[Duncan P]

It depends how your processes are being called, but if you are interested in parameters for processes called from within other processes they will appear as function arguments to the ExecuteProcess function in the calling process.

[paulsimon]

Hi

I did try TM1.Process.Function.Parameters=ON (and OFF), however, that then logs every function that is called in the process, which creates too much logging. I am not really wanting to use this for debugging. I just want a record of the parameters that were passed to the process. We already have a cube in the system that logs calls. However, it requires a lot of developer time to ensure that the relevant parameters are logged by a call to the logging process in each process. Even then the scheme we have here only logs the details for the most recent process call, which when you have 200 people all doing forecasting doesn't always help. I have seen other schemes that add a list dimension to the process logging cube so that all calls can be captured, but then this cube can get quite large.

It just occurred to me that TM1 must have this information, so if there was a way to get it written to the TM1 Server Log then that would save developers the trouble of writing code to do it, and it would also allow the call to be placed in the context of other calls.

I will try to raise an RFE.

Regards

Paul Simon

[Duncan P]

It's a good one for an RFE. But until that comes along ...

We used to have our own additional logging and a convention that all processes would log their parameters as the first thing they did when they executed. I was working with a very organised chap at the time who set up all the infrastructure. There were also processes which would scan the .PRO files of all the other processes to see if they had the necessary parameter log lines. If a process was going to be called a lot (e.g. once per row of a large import) then there would need to be a first line comment excluding it from the requirement for performance reasons.

It should even be possible to write code in TI to analyse your .PRO files to determine what the parameters are and insert the required logging code if you so wish.

[sachin]

If you are on 10.2.2 then you can use LogOutput function to write to tm1server.log. Check the below post
https://everanalytics.wordpress.com/201 ... ognos-tm1/

Unlike tm1s-log entry, this approach however requires you to write the desired code in every process you want to track, in the first few lines of PROLOG tab. HTH.