When creating a shared job, I'd like to leverage details from the context the job is being called in.
A more specific use case- we leverage shared jobs to standardize data testing. The shared job runs a standardized test, then centrally logs the result and sends notifications when necessary. I'd like to include context in that log, such as the job and component name (maybe schedule info as well?) given to the shared job component in the calling job.
I'm thinking my requested information might also be called the run context. Can the context of a run be accessed within the run itself?
I am about to post an Idea about this, but wanted to see if the community has an existing solution first.
Thanks!
Brendan Carlquist
It has also occurred to me that this information could be made accessible to any orchestration or transformation that is nested in a calling orchestration, not only shared jobs.
You can pass them as parameters to your shared job , for e.g , calling job name etc and reference them inside the shared job, while logging the result.
Thanks, Anudeep. If the data isn't available through an automated means, that sounds like a good workaround.
My goal was to limit the introduction of error in this workflow. As parameters to the called job, they could be ignored or misspelled. They will require maintenance if the context is changed. I'm not sure how schedule info could be included in this manner, either.
Has anyone come across a more automated solution?
If anyone is also interested in leveraging run context in their shared jobs, I have submitted this as an idea for the matillion team here: https://metlcommunity.matillion.com/s/idea/0874G000000Q2fQQAS/detail
In the mean time, Anudeep provided a solid workaround to use. I will personally be including a single 'test name' parameter in the definition of my shared jobs, that will suffice for very rudimentary run context in the logs. Its not ideal compared to real run context, but it'll work for today. Thanks, Anudeep!