Wednesday, December 4, 2013

ODI debugger - Part 2

Descendant Sessions debugging

In ODI one Session can launch a child Session in different ways.
  1. user can have an OdiStartScen tool invocation either in Package or Procedure
  2. user can have an OdiInvokeWebService invocation either via Package or Procedure
  3. user can have an OSCommand or OdiOSCommand tool invocation calling startscen.sh/cmd or restartsess.sh/cmd either in Package or Procedure
ODI debugger will notify the client about debuggable child Sessions start only in case (1). In this case you need to be aware of one fact. Child Sessions inherit debug flags set on the parent Session unless they are explicitly overridden by debugger properties set on OdiStartScen. So if parent Session has the flags DEBUGGABLE=true and DEBUG_DESCENDANT_SESSIONS=true set, then any child Session would be automatically debuggable and *its* children would be debuggable and would start any of their child Sessions also in debuggable mode. This gives the user a very flexible debug configuration. User may want to launch the root Session in non-debuggable mode, but have a specific child Session debuggable. Or they might want it the other way, some children to be debuggable while others are not.

There is another subtle gotcha. When ODI Studio notifies you that a child Session is starting, if user chooses not to attach Studio to that debuggable Session, then user *will not receive any notifications for any debuggable child Sessions started by this child Session*

Starting Session in debug mode


All the ways for starting a Session have debugger flags that user may set. This includes startscen.sh/cmd, restartsess.sh/cmd, ODI incoming web service (a.k.a public web service), OdiStartScen tool, SDK APIs and Studio.

No comments:

Post a Comment