We're looking to start creating incidents via the SDK, at first creating them from internal systems like our syslog-monitor, but then perhaps from external sources too. I can create the incident no problem, but it appears to me that the process is very fragile because of the number of internal identifier numbers involved. If we change default projects, workflow steps, users, statuses, etc. then all the ids could change. This is annoying for local code, but catostrophic for code running on machines we don't control (or have minimal control over).

So... We're thinking of having the remote systems make a web service call to a new service we create which will create an "empty" incident with all the default values we want to assign to the incident and we'll return that id. Then the remote system can change the fields it needs to and then update the incident. This way if we want to change the default ids the only place they're used is in our local "GetNewIncidentWithDefaults" service. Still not pretty, but at least we control that.

Am I missing something? Is there a way to have ontime create an incident with the appropriate default values? If not, how are others dealing with these issues?

-Walden

I use sql queries directly on the OnTime DB to build a map of type ids to the names (e.g. "select SeverityTypeId,Name from SeverityTypes"). This is done once (for each type... Severity, Priority, Workflow, etc) during initialization of an object that connects to OnTime, and then after that I can just access values using the names instead of the numbers, and changes are taken care of automatically.

It would be nicer if the SDK allowed you to specify by name instead of requiring the ids so that this was not necessary

 

Instead of going directly to the database to get the list of severities, you can use the TypeHandler class in the TypeService.asmx and call GetSeverityTypes()

---

Dan Suceava
http://www.axosoft.com

Thanks Dan, I didn't realized it was exposed like that.