JavaScript and WOB._state

[TRAVIS ANDERSON]

I'm having trouble getting the correct state displayed when using the wob state. What I've done is had a job in manhold state then go overdue. The job will run an alert when overdue and is supposed to pass the state of itself. It is passing overdue even though the state in the client is manhold. This is true also with jobs that are predwait state, the state that the variable resolves to is overdue.

 

Anyone else seen this happen?

[Andy Reimer]

Looking at the manual,  I don't see MANHOLD or PREDWAIT listed as available values, if that was what you were expecting.  WOB._state is listed as "Alerts only" and only alert status types apply.

 

Try looking at WOB._status
Specifies the job status sent by the agent/advanced integration or the server. You can use this symbolic variable in a JavaScript script from an Application or an Alert.

[TRAVIS ANDERSON]

I am using the WOB._status and the status is getting passed fine. However, I'd really like for the state of the job to be passed also so that when our application users get a ticket created for it, they can see also the state in which the job is in (whether it is on manhold or predwait due to waiting on predecessors, etc).

 

Example, a job I am testing the details is below, grabbed from the client. It fired off the overdue alert when it became overdue, can I not have manhold passed as the state? It is instead passing overdue everytime as the state and then being i am also using wob._status, the ticket will display "Overdue due to late completion". Just trying to get a little more info passed that may help inform our teams of why it is overdue, in this case because it is on manhold.

 

State MANHOLD
Job Type UNIX
Predecessors HOLD
Conditions Overdue Predwait
Status Overdue due to late completion.

[Ravi Kiran Kunduri]

Hi,

 

Can you confirm if you are using the Javascript in Alert or in Job-level Javascript.

 

Thanks and regards,

Ravi Kiran

[TRAVIS ANDERSON]

Hi Ravi, the way our shop is setup we have the jobs using the same type of alert. Within it the JS will pass the information such as wob._state and wob._status, etc to another job within another app. That job when ran is what will create our tickets. The JS I have running in this job that creates the ticket is ran at event trigger time

[SHARON SHIMANEK]

we only alert on SUBERROR, FAILED or OVERDUE so our tickets are cut with the correct state. 

 

I did test when a job is on MANHOLD or PREDWAIT and go overdue and the data is just passed as OVERDUE, most likely because in notifications that is the state that triggers the alert or email.

 

Looks to me like the STATE that gets past is considered Monitor State (not actual job state) - only the states listed on the notification email/alert/snmp are passed

 

Monitor States

You can set up notifications to notify users or act when a job reaches a certain state. You can set up notifications for the following job states and conditions:

Abandon submission

Agent down

Complete 

Exec

Failed

Force completed

Global variable wait

Inactive

Monitor

Overdue

Premature end

Ready

Resource wait

Step complete

Suberror

Suspend

Unknown

 

Sharon

[TRAVIS ANDERSON]

Thanks Sharon. What I am wondering though is if it is the way I have things setup or is it something that the product should not being doing. I understand the states that can be notified upon for the alerts section but when you check to be notified upon overdue and the alert that gets fired for that passes the wob_state, i'm not understanding why a state of overdue gets passed. Overdue is just the what you are monitoring for, overdue is not an actual state of a job but is a condition.

 

What I am wanting is to see the actual state such as applhold or manhold. These are job states, overdue is not.

[Olusegun Oduntan]

If you are monitoring for overdue, the WOB._state value for the Alert is Overdue. There is no WOB._state value for APPLHOLD and MANHOLD. For more information, please see the docs - WOB-prefixed Built-in Symbolic Variables.