We use the Snow API to monitor the DUJ time every day. However, we don't think it gives the correct execution time.
Here's an example:
The LastExecutionTime shown is not for 26th Feb, we think it's the execution time for 25th, so it looks like it's one day out!
Has anybody else noticed this?
Hello David,
I have just checked in our environment and everything is fine. The information about the DUJ is correct.
best regards
Lars
Thanks! That's interesting, ours definitely seems to be one day out. What version of SLM do you have Lars?
...here's a specific example. On March 1st our DUJ execution time was 02:17, however the API says 03:15 like this:
But when we look at the DUJ from one day before, on Feb 28th, then the execution time was 03:15:
So in our case, the REST API definitely seems to be one day out... Perhaps this bug only happens with a specific version of SLM? I'm wondering if it's an SLM 9 bug?
Ok you are right... we use SLM API Version 9.0.6969.27845 and i see now a difference.
The Smacc say the LastExecutionTime was 00:52:26 but the API say 01:04:00.
that's strange. yesterday was it ok... a cache problem?
Thanks for checking, it’s good to know. I don’t think it’s a cache problem, because the date changes, it’s only the execution time that seems wrong. I reckon it’s just bug. But it’s really helpful that someone else has seen it too It means I’m not going crazy .
Lars, perhaps you just had two days with similar DUJ times, that would make it more difficult to spot...
Regards, David
Yes that could be. We should check that for the next 2-3 days.
Hello there, the same for SLM 8.3.07
Starting with API to see if I can use it in PowerShell and run into this entry. Just to add more information.
The SLM SMACC tells me execution time is : 01:25.53
| State | FinishedOrOnlyMinorErrors |
|---|---|
| LastStartTime | 5-3-2019 04:00:00 |
| LastExecutionTime | 01:18:00 |
| IsRunning | False |
Snow Software REST API v8.3.6968.20415 @ 5-3-2019 10:29:39
Regards,
Marcel
Thanks Marcel! We have written a PowerShell script which monitors this API call every day and sends out an e-mail with the details, it should be a very useful thing. However, it's somewhat limited because the LastExecutionTime is a day behind. It's useful to know that SLM 8.3.07 has the same issue, thanks for the confirmation.
Regards, David
Hi DavidHobbs
When you only want to get an email notification of DUJ results, then you also could do this directly in the database. Perhaps this way may help you: Snow Daily Maintenance Notifications
This provides a daily notification with correct run times
JOB RUN: 'License Manager Data Update' was run on 03.01.2019 at 00:00:00
DURATION: 2 hours, 22 minutes, 37 seconds
STATUS: Succeeded
MESSAGES: The job succeeded. The Job was invoked by Schedule 21 (Recurring). The last step to run was step 38 (End job).
Regards, Carola
Thanks Carola, that's a really good thing to know about.
However, our PowerShell script monitors a lot more about Snow. It tells us the status of all the services running on our Snow Servers (Inventory and SLM). It also tells us the number of snowpack files waiting to be processed in the file system of the Inventory server. The idea is to get a reasonably comprehensive snapshot of how Snow is operating. The DUJ information is just a part of that.
So, each morning when we open our e-mail we get to see if Snow is healthy or not. I find it very useful. If the REST API can be changed to show the correct execution time, it will be even better though
I have put it on the ideas board, here: REST API to provide the correct DUJ execution time
I would see this more as a bug, than a feature request in the idea's board.
So I think, when you create a support ticket, you should get a quicker solution.
A problem record has now been created for this issue. It looks like the LastExecutionTime reported by the REST API currently comes from the tblJobLogHistory table which is a day behind. So the data seems to be coming from the wrong table.
If the execution time can be taken from tblJobLog instead then it should be correct I think.
Regards, David
Bizarrely, in a strange twist, Snow Support have now changed their mind and decided that this API call is working as designed. So apparently, they are saying it is supposed to provide the date of the most recent DUJ, along with the execution time of the DUJ one day before. I can't really see a use case for that...
But they did share the SQL source of the stored procedure with me, and I can see that most of the data returned by this API call comes from tblJobLog, however the LastExecutionTime definitely comes from tblJobLogHistory which is why it is always one day behind.
So it doesn't look like we're going to be able to use the REST API to monitor our DUJ, because the LastExecutionTime is always going to be one day behind. If you are making use of this API call, it's worth keeping that in mind.
David
Hi David,
I don't use the API to get that information, but also cannot understand the answer you got.
Also when it is by design, that can be a bad design that would be worth to be changed. Did you get any worthful explanation why it is designed in that way? For me that does not make any sense.
I also sometimes got such an answer from support,
When there is a valuable explanation, perhaps "necessary for other customers", I accept it.
But when there is no explanation and it's really important for me, then I escalate it by our contacts.
Hi Carola,
Yes, that's good advice, thank you!
I have asked several times for an explanation for this design, but I can't seem to get an answer. It's a shame because it's a very simple SQL change to get the LastExecutionTime from tblJobLog instead of tblJobLogHistory. Daniel Gimm and I looked at it together and found where the data is coming from. We even found a fix together. But now they are now saying the behaviour is by design which seems very odd.
I will keep trying to get a worthwhile answer about the current design. Thanks again.
David
Sorry to throw my oar into this discussion, but SNOW's argument doesn't make any sense....Carola - can you get someone to explain it better please? Surely this must show the same data as the last start time?
Thanks
Adam
Hi Adam,
You probably meant me, not Carola? Anyway, you are welcome to throw your oar in :-) I am really trying to get Snow Support to explain, because it doesn't make sense to me. However I am not getting an answer about their design choice. For example, here is their latest response:
Last execution time is the previous Data Update Job time, the name is misleading as it would lead you to believe that would be the one that has just happened not the previous one.
The fix they are planning to make is to change the name to something other than LastExecutionTime and leave the logic the same. I cannot understand that design choice - but I have not been able to get them to explain it either.
If you have time, feel free to raise your own ticket, because that may add some weight to the discussion. I am probably the only one who has logged a ticket about it.
Best Regards, David
Hi David
Yes I did! Sorry Carola. I will log a ticket with them too to see if we can get this changed... It really doesn't make any sense to me either.
Thanks
Adam
Hi David
Case CS0065133 logged.
Hi David
So support tried to close the case with a similar reason to you...
Resolution proposed: Hi Adam, LastStartDate: A: The DUJ will only display the latest date of when it run. That means if today is 29/10 then the last DUJ has run on 28/10 9PM. This is how the information has always been listed. The LastExecutionTime displayed in the API actually shows the time for the previous DUJ execution A: That is the time that the DUJ has taken to complete. However, if you would like this to be changed please log a comment on our Ideas Board for our Devs to investigate. https://snow-software.jiveon.com/community/news-at-snow/blog/2018/07/02/snow-ideas-board As nothing is broken and the information is displayed correctly I will now close this case.
I've reopened the case and provided screen shots to demonstrate that the last execution time is not correctly being displayed. Will let you know what they say.
Thanks
Adam
Thanks Adam!
That's interesting, because I already put an idea on the ideas board and they closed it: REST API to provide the correct DUJ execution time
So ... I put it on the ideas board and they close it saying to log a ticket. Then you log a ticket and they say put it in the ideas board!
But really, I still can't believe that this isn't a bug, and I don't understand why it can't just be fixed. Why would anybody need to know the date of the last DUJ along with the Execution Time of the previous one from the same API call? And Oliver's comment also seemed to indicate that it's a bug. So I really hope they can fix it, because we'd like to make use of this API call.
Please keep us updated!
Regards, David
Hi David,
I don't know why the initial design was made to display the previous job run rather than the most recent one in the LastExecutionTime field. When clicking the field in the API, the description says the following:
Either way I'll look into this and see if we can just change it for the next release of SLM as I think it makes more sense to display the most recent jobtime. No promises though, as I don't yet know if this will cause issues somewhere else that would then also have to be altered, etc.
Best / Jonas
Thanks Jonas,
I really appreciate your reply, it's really encouraging. I also tried to see the description, but for me, when I click the field it just says this:
I wonder why you get the documentation and we don't? Out of interest what description do you get for LastStartTime?
It looks like a one-line SQL fix where tblJobLogHistory can be switched to tblJobLog. Like you say, as long as there are no knock-on effects. If there are issues with the change, maybe another API call (eg /api/latestduj/) could be included side-by-side, which would be more useful.
Thanks again! David
Hi David,
Oh, I didn't realize that the documentation of the different fields in the API was missing. I suppose that means that the build server that is generating SUS packages isn't building the documentation files properly right now. They are built without issues for me locally: 
(This screenshot includes my updated description of the LastExecutionTime field. Compare it to my previous screenshot to see current behaviour up until version 9.5.0 of SLM):
Not sure I'll be able to affect the build server in time for release but, I believe I have managed to change the behaviour of the field (it works in my tests, but regression testing has not yet begun so I can not yet be 100% sure).
I hope this helps / Jonas
Thank-you! I will check with others on the Community and see if anybody can see the documentation of the API fields. It would be so helpful to have that documentation if it is available. I will try to find out if it's a common problem. On our system, everything says: No documentation available.
And if the behaviour of the LastExecutionTime field can be changed for a future release that would be awesome :-)
Regards, David
Hi David,
Current status on this is that my changes are included in SLM 9.6.0, which is currently in beginning of the regression phase.
LastExecutionTime is in my testing now listing the most recent run time of the data update job, and the XML's with the full API documentation is included in the package that will be delivered via SUS so customers can properly see the description of the fields.
Unsure on the exact date for 9.6.0 but if you have cases linked to the PRB for this, you'll get an automatic update via that when the release is made available for download.
Please consider updating the 'correct answer' in this thread so others are made aware that a change is planned.
Best regards / Jonas
Thanks Jonas, that's really appreciated. It will help us a lot, because we're using the REST API to monitor SLM and send out notifications, so being able to keep an eye on the DUJ execution time will be extremely useful.
David
This seems to be PRB0042823 and is now on the release notes for SLM 9.6.0. We're looking forward to it
me too!! never understood their logic behind why it was the way it was :-)
Here's the latest from my ticket. When asking about why it has been designed this way, the response I get is:
This is not something I can answer I'm afraid that is more something that the R&D team may be able to answer. Would you mind asking this on the forum for one of them to come back to you if possible.
So I wonder if somebody like Andreas or Joel might be able to explain why the LastExecutionTime comes from tblJobLogHistory rather than from tblJobLog? Why would the REST API be designed to be one day behind when reporting LastExecutionTime?
Regards, David
I second that Jonas - and I can't see the documentation field either
Thanks
Adam
Hi Adam, the API documentation should be availble in a future release. Please see my latest update in my thread with David, above, for more details.
Best regards / Jonas
thanks Jonas for the update!
my pleasure - that's what this community is for!
on Feb 27, 2019
Hi David,
Current status on this is that my changes are included in SLM 9.6.0, which is currently in beginning of the regression phase.
LastExecutionTime is in my testing now listing the most recent run time of the data update job, and the XML's with the full API documentation is included in the package that will be delivered via SUS so customers can properly see the description of the fields.
Unsure on the exact date for 9.6.0 but if you have cases linked to the PRB for this, you'll get an automatic update via that when the release is made available for download.
Please consider updating the 'correct answer' in this thread so others are made aware that a change is planned.
Best regards / Jonas