How to get a Subsystem to produce an output

johndanter

johndanter

Legendary Poster
Hi folks,

I've just written a subsystem to help with our shipping info. All this is working fine except I now have no visibility of it's output.

I see the record added to F986113, I see it then clear down, I can also see all the relevant database updates occurring in F4943 F4216 too. So I know it works, I just have no trace or CSV/PDF that this job ever executed.

So how do I get get my subsystem to produce it's CSV each time? I need this as if there is an error I am reporting them in the CSV

Thanks

John
 
Hi Serg

Yes I use this often, I love it. I meant the actual UBEs output. I email people if things go wrong and direct them to the job number but I'd like them to be able to see the PDF themselves.
But I could always attach it to the email
 
Subsystems don't produce a PDF per trigger. Going from memory here ... the PDF only appears when you end the subsystem is ended and IIRC it will be the most recent triggered run of the job.

If you want the PDF from each triggered event, I think could have your subsystem be a driver and do async launches of the PDF producing UBE (into a different queue if the subsystem queue is not multithreaded)
 
Thanks
What me and CNC team seem to have spotted is this:

If I launch the SBS and it has job number 7382370 then everytime, everytime you launch the SBS a file can be found in the print queue under the name

R554216_RRD0001_7382370_PDF but.......

The contents of this file gets overwritten each time. It's quite interesting. So I've ran this twice today and each time there is only one file in the servers print queue with this name.
However the content changed each time :)
 
That's one of the reasons we don't use Sub-System Jobs here but instead have a Driver UBE that polls for Data (Event), if found submits child UBE otherwise sleeps 30 seconds and repeats.
If we want to stop the driver we just insert a special STOP message into the table its monitoring.
 
That's one of the reasons we don't use Sub-System Jobs here but instead have a Driver UBE that polls for Data (Event), if found submits child UBE otherwise sleeps 30 seconds and repeats.
If we want to stop the driver we just insert a special STOP message into the table its monitoring.

You rolled your own sub system. To be honest, with multi-threaded queues I never really understood the need for the default JDE sub-system anyway. Other than a guaranteed "slot" in the job queue what are the other advantages?
 
That's one of the reasons we don't use Sub-System Jobs here but instead have a Driver UBE that polls for Data (Event), if found submits child UBE otherwise sleeps 30 seconds and repeats.
If we want to stop the driver we just insert a special STOP message into the table its monitoring.

On one of the previous projects we used exactly the same approach, with several master UBEs (one per required schedule) and a bunch of child UBEs spawned from the master.
It had been working like a charm for years, but eventually was completely phased out by the real-time BSSV integration.
 
Not much more to tell John. All UBE's are regular UBEs.
The Driver UBE just doesn't end normally. Just loops reading a table that tells it what to do/process. Based on data/parameters read it can:
- Process the data itself
- Submit a child UBE passing parameters
- End if Quit message read or you may hard code a time to stop processing (like 7am)
If you need to do something with the Output created (email, etc) then the Child UBE is the way to go.

The Driver UBE is normally launched via scheduled jobs at startup however we did create a simple application (normal JDE app) that can launch the driver ube or stop it gracefully under User control.
 
... To be honest, with multi-threaded queues I never really understood the need for the default JDE sub-system anyway. Other than a guaranteed "slot" in the job queue what are the other advantages?


Since subsystems init the EOne environment and load specs into RAM (even for child UBEs) via Metadata kernel only once, they have a much higher throughput for the very short jobs. Once the jobs get long enough that starting the environment/reading specs is a tiny fraction of the time, then you don't need subsystem.

Also, since they process as data enters the F986113 as triggers, it can automate a lot of things. Although BSSV is another way of triggering a lot of things, as is using the AIS notification framework.
 
Last edited:
Back
Top