Hi Stefan,

I will attempt to provide some answers where I can.

the full list of the local fields (properties) of the events

Using the below should get you all system fields…

http://<Server><Port>/assystREST/v2/events/<eventId>?fields=*

how to get the reference fields (for example: to know that affectedUser is another entity/collection and so on...)

If I understand your need correctly then you will want to use…

http://<Server><Port>/assystREST/v2/events/<eventId>?fields=*,affectedUser

what about the custom fields and how to discover them

Pulling custom fields…

http://<Server><Port>/assystREST/v2/events/<eventId>?fields=customFields,customFields.singleSelectValue,customFields.systemLookupValue,customFields.multiSelectValues

In combination to pull the event, affected user and custom fields.…

http://<Server><Port>/assystREST/v2/events/<eventId>?fields=*,affectedUser
,customFields,customFields.singleSelectValue,customFields.systemLookupValue,customFields.multiSelectValues

Another useful example to take this one step further. Pulling the parent event details when pulling task or decision information and drilling into the users related properties…

http://<Server><Port>/assystREST/v2/events/<eventId>?fields=?fields=*,parentEvent
,affectedUser[*,rolee],manager*]]

what are the supported Actions for the relevant event type and what are the actionType IDs - for example I realised that to create a comment to Incident 

Actions are defined by system admins (with the exception of some of the core actions). I think this could be different for each of us. The easiest way to find an id of anything in the system is to look at the URL when viewing the entity. The below is an example of an action with the id of 326…

https://<domain>/assystweb/application.do#management%2FActionType.do?dispatch=getPrimary&id=326

how to change the Status of an event?

If you mean (for example) resolving an event, you can do this by posting an action. The body of an Api can be built using XML or Json, whichever you are more comfortable with. I have included an example from our workings to get you going.

{
	"actionType":  {
			"resolvingParameters":  e
				{
					"parameterName":  "shortCode",
					"parameterValue":  "RESOLVED"
				}
			]
		},
		"actionSuccess":  true,
		"remarks":  "This is an action",
		"causeCategory":  {
			"resolvingParameters":  e
				{
					"parameterName":  "id",
					"parameterValue":  547
				}
			]
		},
		"serviceTime":  {
			"value":  2
		},
		"causeItem":  {
			"resolvingParameters":  e
				{
					"parameterName":  "id",
					"parameterValue":  10547
				}
			]
		},
		"actionedBy":  {
			"resolvingParameters":  e
				{
					"parameterName":  "id",
					"parameterValue":  1209
				}
			]
		},
		"eventId":  123456789,
		"actioningServDept":  {
			"resolvingParameters":  e
				{
					"parameterName":  "id",
					"parameterValue":  2
				}
		]
	}
}

I hope something in there helps.

Hi Steve,

your examples are very good and helpful.

What I am more concerned is if it is possible and how to discover the data model/structure of the events via the API from the metadata/definitions (without checking on the UI). In other words to know for example:

• all local fields for the events (plus all available values for the select list fields)
• all reference fields
• all custom fields
• all action types and their IDs
• all required fields when do a POST request

Are all of these possible to achieve and build the data model by using some of these endpoints from the doc:

• /events/schema
• /raml
• /events/raml
• /events/incident/definition

The last one /events/incident/definition returns this data which looks good but I noticed there some differencies with the field names - for example when I get 1 event by ID - fields like 'eventStatus’ or 'eventState’ are with other names here in this reponse (maybe there are more other field names mismatches)

Thanks again,

regards Stefan