Null pointer exception in Input Ticket Audit

[matthewtckr]

Null pointer exception in Input Ticket Audit

[matthewtckr]

Thanks for the stack trace. It sounds like you may not have an "Error handling" hop in your transformation, which may be causing the NullPointerException when it tries to find that hop to write the error row.

If that doesn't resolve the issue, can you send me an email (redacted) with the attachment, so I review it? Be sure to strip any username/password settings from the file before sending.

Let me know if that helps.

[marco44]

It's exactly the problem… I had no error step. Thanks a lot.

[marco44]

Sorry I'm a beginner, but I have almost 10% of these records in error. I see in the example in the wiki a «remove invalid ticket ids» step, is this linked ?

[matthewtckr]

The example screenshot is from my own PDI transformation that I run daily. In my case, there are some tickets that for whatever reason exist only in the Incremental Tickets API, but not in any other API endpoint. I've never gotten a good answer as to why this happens, unfortunately.

When I come across those specific Ticket IDs that I want to avoid, I just add those Ticket IDs into a Data Grid step, and have a filter to prevent me from asking for Ticket Audit records for those Ticket IDs.

If you're getting 10% of your tickets responding with a 404 error, do you see them in the Zendesk UI when you're logged in as an admin? If you do see them, you might need to raise a ticket with Zendesk Support asking why the API does not return the ticket information. If you do not see them in the Zendesk UI, you may want to ignore, or actively filter them like in my example.

[marco44]

Ok, that's much clearer, thanks.
Another question (I hope it's the last one), I see in the example that you are using the table output. I don't understand how this doesn't produce duplicates, if a ticket has been updated ? I would, instinctively, have used an insert/update step...

[matthewtckr]

I send everything into a truncated staging table, and then have another SQL query that handles the insert/update into the final table after that transformation.

This helps to avoid any PDI<->Database latency as Insert/Update typically has to do a round-trip for each record.

[marco44]

Ok, seems logical. Thanks a lot !

[marco44]

Ok, we dug a bit into the zendesk UI with a colleague which is more proficient than me. It seems that these are delete tickets. As we only have the latest deleted tickets in the GUI, we can only check for those, but there is a 100% match with recent deleted tickets. So the API returns even ids of deleted tickets, which cannot be retrieved. And they confirm me that they did a lot of tests a while a go, and the big amount of deleted tickets and their range is consistent with that.