Details
-
Fix
-
Status: Released (View Workflow)
-
Minor
-
Resolution: Fixed
-
1.8.4, 1.9.8, 1.10.2
-
None
Description
Current Situation
- The sync job considers orders that have the same sync_session_id.
- The Splitter job creates orders with the parameter sync_session_id
- The value for this parameter is <job_chain><syncnode><orderid>
- This will be done to reuse a sync job for multiple splitter nodes in one job chain.
- When the sync job also is used to synchronize different job chains, the orders will have different sync_session_id and will not be released.
- In JobScheduler 1.10.0 the orders will be released as the sync job did not evaluate the sync_session_id correctly. See
JITL-238 - In JobScheduler 1.10.2 it can happen that orders will not be release because they have different sync_session_id which will be handled now correctly.
Desired Behaviour
The Splitter job should not create orders with the parameter sync_session_id by default
The Splitter job should create orders with the parameter sync_session_id when the option create_sync_session_id is set.
Workaround
You can add a preprocessing script to the sync job like this
<script language="java:javascript"> function spooler_process_before(){ spooler_task.order.params.set_var("sync_session_id","") return true; }
Explanation
Question: What is the purpose of the sync_session_id?
Answer: The sync_session_id creates a context for the Sync job. The job considers only orders that have the same sync_session_id. This can be usefull when you want to multiuse the same Sync job for different splitters.
Question: When do without sync_session_id?
Answer: If you build the context for the sync job by defining different jobs for each context the sync_session_id is not necessary. This is recommended.
Attention
Because of JITL-149 the attached example jitl-279.zip does not work with JobScheduler 1.8.5. Use jitl-279-for-1.8.5.zip instead.
Attachments
Issue Links
- relates to
-
JITL-238 Sync job should handle the sync_session_id correct
- Released