OdiStartScen threw "The scenario did not end properly" Exception

Question

Hello,
I tried to use ODI to do the "CDC", but OdiStartScen, which i used to start the scenario continually, threw "The scenario did not end properly" Exception at the end of process of my package. The process is "OidWaitForLogData --> extend window --> interface --> purge window --> OdiStartScen";
java.lang.Exception: The scenario did not end properly.
     at com.sunopsis.dwg.dbobj.SnpScen.a(SnpScen.java)
     at com.sunopsis.dwg.dbobj.SnpScen.localExecuteSync(SnpScen.java)
     at com.sunopsis.dwg.tools.StartScen.actionExecute(StartScen.java)
     at com.sunopsis.dwg.function.SnpsFunctionBaseRepositoryConnected.execute(SnpsFunctionBaseRepositoryConnected.java)
     at com.sunopsis.dwg.dbobj.SnpSessTaskSql.execIntegratedFunction(SnpSessTaskSql.java)
     at com.sunopsis.dwg.dbobj.SnpSessTaskSql.treatTaskTrt(SnpSessTaskSql.java)
     at com.sunopsis.dwg.dbobj.SnpSessTaskSqlS.treatTaskTrt(SnpSessTaskSqlS.java)
     at com.sunopsis.dwg.dbobj.SnpSessTaskSql.treatTask(SnpSessTaskSql.java)
     at com.sunopsis.dwg.dbobj.SnpSessStep.treatSessStep(SnpSessStep.java)
     at com.sunopsis.dwg.dbobj.SnpSession.treatSession(SnpSession.java)
     at com.sunopsis.dwg.cmd.DwgCommandSession.treatCommand(DwgCommandSession.java)
     at com.sunopsis.dwg.cmd.DwgCommandBase.execute(DwgCommandBase.java)
     at com.sunopsis.dwg.cmd.e.i(e.java)
     at com.sunopsis.dwg.cmd.g.y(g.java)
     at com.sunopsis.dwg.cmd.e.run(e.java)
     at java.lang.Thread.run(Thread.java:595)
OdiStartScen "-SCEN_NAME=JOURNALIZEPACKAGEDEMOSCEN" "-SCEN_VERSION=002" "-CONTEXT=GLOBAL" "-LOG_LEVEL=5" "-SYNC_MODE=1" "-ODI_USER=SUPERVISOR" "-ODI_PASS=d,yXgLJMwXJsIhe0qMX.X9PPn"
Does anyone have an idea of what is the problem ?
regards

Answer 1

(From ODI user's guide/MODEL/ Change Data Capture)
Using Changed data in Consistent journalizing is similar to simple journalizing regarding interface design. It requires extra steps before and after processing the changed data in the interfaces, in order to enforce changes consistently within the set.
Operations Before Using the Changed Data
The following operations should be undertaken before using the changed data when using consistent set journalizing:
Extend Window: The Consistency Window is a range of available changes in all the tables of the consistency set for which the insert/update/delete are possible without violating referential integrity. The extend window operation (re)computes this window to take into account new changes captured since the latest Extend Window operation. This operation is implemented using a package step with the Journalizing Model Type. This operation can be scheduled separately from other journalizing operations.
Lock Subscribers: Although the extend window is applied to the entire consistency set, subscribers consume the changes separately. This operation performs a subscriber(s) specific "snapshot" of the changes in the consistency window. This snapshot includes all the changes within the consistency window that have not been consumed yet by the subscriber(s). This operation is implemented using a package step with the Journalizing Model Type. It should be always performed before the first interface using changes captured for the subscriber(s).
Designing Interfaces
The changed data in consistent set journalizing are also processed using interfaces sequenced into packages.
Designing interfaces when using consistent set journalizing is similar to simple journalizing, except for the following differences:
The changes taken into account by the interface (that is filtered with JRN_FLAG, JRN_DATE and JRN_SUBSCRIBER) are not automatically purged at the end of the interface. They can be reused by subsequent interfaces. The unlock subscriber and purge journal operations (see below) are required to commit consumption of these changes, and remove useless entries from the journal respectively.
In consistent mode, the JRN_DATE column should not be used in the journalizing filter. Using this timestamp to filter the changes consumed does not entirely ensure consistency in these changes.
Operations after Using the Changed Data
After using the changed data, the following operations should be performed:
Unlock Subscribers: This operation commits the use of the changes that where locked during the Lock Subscribers operations for the subscribers. It should be processed only after all the changes for the subscribers have been processed. This operation is implemented using a package step with the Journalizing Model Type. It should be always performed after the last interface using changes captured for the subscribers. If the changes need to be processed again (for example, in case of an error), this operation should not be performed.
Purge Journal: After all subscribers have consumed the changes they have subscribed to, entries still remain in the journalizing tables and should be deleted. This is performed by the Purge Journal operation. This operation is implemented using a package step with the Journalizing Model Type. This operation can be scheduled separately from the other journalizing operations.
To create an Extend Window, Lock/Unlock Subscriber or Purge Journal step in a package:
Open the package where the operations will be performed.
Drag and drop the model for which you want to perform the operation.
In the Type list, select Journalizing Model.
Check the option boxes corresponding to the operations you want to perform.
Enter the list of subscribers into the Subscribers group if performing lock/unlock subscribers operations.
Click OK.