a hold-all json blob which can include any details a client request wishes to expose to potential workers. It could contain e.g. session information, the submitting or 'run-as' user, etc.
an instruction on which/how to select matching work subscriptions as an opportunity to filter on best-fit
if true, the job submission to the exchange should block until one or more matching worker(s) is found
the json criteria used to match work subscriptions
should the 'workMatcher' not match _any_ current work subscriptions, the SubmitJob is resubmitted with the 'orElse' criteria
a hold-all json blob which can include any details a client request wishes to expose to potential workers.
a hold-all json blob which can include any details a client request wishes to expose to potential workers. It could contain e.g. session information, the submitting or 'run-as' user, etc.
if true, the job submission to the exchange should block until one or more matching worker(s) is found
should the 'workMatcher' not match _any_ current work subscriptions, the SubmitJob is resubmitted with the 'orElse' criteria
an instruction on which/how to select matching work subscriptions as an opportunity to filter on best-fit
the json criteria used to match work subscriptions
(Since version ) see corresponding Javadoc for more information.
The SubmissionDetails is the ansillary information submitted with a job request.
Where a typical REST endpoint would just take some POSTed json request, the SubmitJob requests wraps that json together will some information intended for the Exchange in order for it to match the job with a worker.
The SubmissionDetails is that additional information to act as instructions/information specific to the job scheduling/matching. It contains:
a hold-all json blob which can include any details a client request wishes to expose to potential workers. It could contain e.g. session information, the submitting or 'run-as' user, etc.
an instruction on which/how to select matching work subscriptions as an opportunity to filter on best-fit
if true, the job submission to the exchange should block until one or more matching worker(s) is found
the json criteria used to match work subscriptions
should the 'workMatcher' not match _any_ current work subscriptions, the SubmitJob is resubmitted with the 'orElse' criteria