Displaying warning icon in BODS admon console

dataservices job design
1

I want to display warning icon (Yellow icon) in BODS management console manually based upon certain condition and error/warning messages are to be displayed in error file/screen.

I can do it using raise_exception in the Try-catch block after the tweaking the parameter TREAT_CATCH_EXCEPTION_AS in DSConfig.txt from SUCCESS to WARNING. (Using Try-Catch stage not Try-Catch in the script,
as Try-Catch block in the script is not able to turn the icon to YELLOW, which Stage Try-Catch Block can do, Which is really wired !!! ).

Now, with TREAT_CATCH_EXCEPTION_AS = WARNING setting if I raise raise_exception in catch block or outside of the catch block it is terminating the job in trace file but console icon does not turn to RED. It remains YELLOW.

But with the settings TREAT_CATCH_EXCEPTION_AS = SUCCESS, it is working as expected, i mean icon turned to RED for the similar case.

I have tested it in BODS 3.1 and BODS 3.2 … But got same result.

So, it seems that SUCCESS to ERROR can be done but WARNING to ERROR can not be done out side of the try-catch stage block.
But I want this as this will give more visual understanding to our production support team, whether error or waring is occurred.

Would anybody please help me ?

I am looking for exciting comments from any senior SAP BODS professional like Werner Daehn …

Thanking you in advance …

HeadsUp (BOB member since 2011-01-14)

2

Can any body provide any update on this ?

HeadsUp (BOB member since 2011-01-14)

3

Hi,

It’s a shame you didn’t get an answer to this, it’s an interesting problem.
I’ve just hit pretty much the same thing; I’d like to propogate a logical warning error from my dataflow into the job status, but it does not seem possible.

raise_exception_ext always generates a full error it seems.
I was not aware of that setting so I hope to go and try this out tomorrow.

Anyone have a solution to this?

Many Thanks

philmorris :uk: (BOB member since 2002-11-12)

4

You may find that writing a message to a file (using a custom function) or using a validation transform to write to a table will give you better granularity of control.

eganjp :us: (BOB member since 2007-09-12)

5

I don’t feel it is a shame. We are here to help each other. We might have missed to answer or no answer was readily available at that time…

If we would need an urgent answer, we would always have to go service.sap.com and we all know how fast we get an answer and we all know why we come here!!! :wink:

Okay let us try to address issues one at a time!!!
First, as Jim suggested, tighten your hands on validations, so that you cover all scenarios!!! For me at least, I feel, Warnings are more dangerous than Errors…So I wanted the Warnings to be treated as Errors!!!

Why?
For example, say you load a VARCHAR() to a DATE column. Now consider an example - 20121301 - YYYYMMDD, convert this to DATE and load into table and see what would happen!!! DI will tell Invalid Month in warning and load a NULL to the table!!! Is this we expect??? Can the ORDER_DATE of an ORDER be empty?

So I made a Custom Function to abort jobs, that had warnings!!!

Post your scenario, and let me see if I can arrive at a solution!!!

ganeshxp :us: (BOB member since 2008-07-17)

6

He he I would never of course even dream of comparing :wink:

I agree that having a good tight control is the way forward and that is certainly the case in what I’m doing here - I’ll expand below.
The issues is however as described and I’m not looking for an alternative. I think this is probably the material of enhancement request but it’s probably too subtle.

When you’re handing BODI code over to an operations team, they rely heavily on the management console and it’s reporting of job status. being able to flag up errors is very useful, especially as it’s quite possible to handle the errors well and continue processing to a neat conclusion.
It is often the case though in my experience that the ‘BIG RED X’ in the console usually generates a false impression of critical/fatal failure of the job.
This is a pain when you’ve trapped an error and handled it, but it’s even worse when you’ve trapped a logical/soft fault, and wish to indicate that action is required but it’s not critical/urgent.
It would be great if the return code of raise_exception_ext allowed a 0 to be success, 1 to be warning and >= 2 to be error. this would chime well with the world of OS errorcodes, Java errorlevel etc.

Anyway, for the interested here is the scenario:

The job is a generic flat file loader that polls a directory and loads whatever it finds. Metadata is encoded into the filename which then determines which source, table, load sequence etc. the file is for.
As the load starts this action is recorded in the DB for auditing and tracking, this call also returns further metadata derived from that in the filename such as which DF should be used to load the file - one of the fields is an indicator of how an empty file should be handled i.e. is this logically a fault, a warning or a normal condition?
The file is loaded, and any fatal errors during that process are trapped and propogated, and at the end of loading the file the DB is again updated to indicate success/warning/error before moving to the next file. Errors at this point therefore show up as Job errors, normal conditions simply printed to the log, but warnings are more tricky because due to this issue there is no way to report this to the management console.

Yes, there is also an email alert, and the logs are polled by BOXI to provide progress/fault tracking reporting.

So hopefully you can see it’s all sewn up pretty tight but the ability to show the warning icon would ice the cake so to speak :slight_smile:

I’m going to go and play with the DSconfig setting indicated by the original poster, and failing that attempt some direct repository manipulation but that is of course not at all ideal.

Hoping someone has a smart idea on this one!

philmorris :uk: (BOB member since 2002-11-12)

7

Phil, over my 5 years of consulting I have found that the most successful ETL projects use a third party scheduler and the jobs themselves send email on failure. There are times that the jobs encounter a fatal error (boom!!) which prevents them from ending gracefully. This is where the third party scheduler comes in handy as it becomes a second tier for handling failure.

eganjp :us: (BOB member since 2007-09-12)