1. xMatters
  2. Community
  3. Integrations & Toolchains

AuditEvent -- limit of 1000?

Clark Bohs
Not Yet Reviewed

Hello,

I'm consuming the SOAP web service and using this object:

QueryEventAuditTrailReturn queryAudit = new QueryEventAuditTrailReturn();

 

I then try to retrieve all the auditEvents but it appears to be throttled on your end at 1000.

auditEvent = {xMattersGetData.xMattersWebService.SoapEventAuditTrail[1000]}

Is there a way for us to retrieve all the auditEvents past 1000?

Thanks!

--Clark Bohs

 

 

0

Comments

4 comments
Date Votes

Please sign in to leave a comment.

  • Travis Depuy

    Hey Clark,

       Yep, looks like it. From the docs here:

    • The result set returned is limited to 1000 audit events.

     

    The new REST APIs are paginated. Have you looked at them? Is there anything in particular you are trying to get in the SOAP API that you can't get via REST?

    Here's the REST docs for the Audit Events: http://help.xmatters.com/xmAPI/#audit-types

     

    0
  • Travis Depuy

    Oh, I do need to mention, that we are working on depreciating SOAP so I would highly encourage moving to REST sooner rather than later. 

    If there are specific things you need that are not in the REST API, then we should see about getting those added. 

    0
  • Clark Bohs

    Hi Travis, I'm using the REST API and I'm trying to figure out how to retrieve the same Audit data as I did in the SOAP call.  Here are example results of the SOAP call:

    EventID Date (ET) Message Type
    1510054 11/13/2017 17:12:24 Starting Event 1,510,054, for incident INCIDENT_ID-1510054, and domain applications EVENT
    1510054 11/13/2017 17:12:24 Notifying CMS Support GROUP
    1510054 11/13/2017 17:12:24 CMS Support - Pointer To CMS Application Support was active and will be notified GROUP
    1510054 11/13/2017 17:12:24 CMS Application Support - 24x7 was active and will be notified GROUP

     

    When I try https://schwab.hosted.xmatters.com/api/xm/1/audits?eventid=1510054 I don't get the results above.

    Thanks!

     

     

     

     

     

    0
  • Travis Depuy

    Hey Clark,

       Ok, so let's break each one down and talk about value what each line is adding:

    1. This is stating that the event was created and shows the event ID. The INCIDENT_ID and the domain have no context in on demand. INCIDENT_ID is just the event number and the domain will always be applications. 
    2. Ok, useful, we're notifying "CMS Support".
    3. Seems that we are notifying a group called "Pointer To CMS Application Support" is a group within the "CMS Support" group
    4. This is the on call shift we are targeting.  

     

    So you should have #1 handy. #2 you can actually get from the GET /event{eventID} API call, doc'd here. I think you'll want to use the ?embed=recipients&targeted=true flavor. 

    But it doesn't look like we can get down to the shift level. 

    What are you doing with this data? Do you need it down to the shift level?

    Happy Monday!
        --- Travis

     

     

    0

Didn't find what you were looking for?

New post