You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Quick drop from my personal notes to share an idea on community.sdl.com...
The existing Get-IshEvent cmdlet allows to retrieve EventLog/EventMonitor information, in essence a centralized logging system for fire-and-forget asynchronous BackgroundTask events. If you will EventMonitor is a centralized log file on steroids. As logging generates a lot of data, the system does clean up of outdated log events in the CMS database.
For some scenarios you would like to do explicit cleanup, this is where Remove-IshEvent relying on EventMonitor25.DeleteByProgressId comes in. Note that removing big amounts of data across the web services API is never the most performant solution. And the only API function for delete requires existing ProgressId identifiers to come in.
Parameter group IshEventsGroup
Mandatory -IshEvent[] that passes existing events, most likely generated by Get-IshEvent and its filters
Optional -DeleteFailedEvent, defaults to true
Optional -BusyFailedEvent, defaults to true
Parameter group ParameterGroup
Expects -ProgressId[], however ISHRemote respects pipeline objects and respects the CMS identifiers. And ProgressId is not considered stable API surface. So IshEventsGroup is preferably used.
Workaround...
As the DeleteByProgressId call is quite simple, one could simply run the below using the WCF-SOAP proxies (probably ISHRemote v0.x only)
Quick drop from my personal notes to share an idea on community.sdl.com...
The existing
Get-IshEvent
cmdlet allows to retrieve EventLog/EventMonitor information, in essence a centralized logging system for fire-and-forget asynchronous BackgroundTask events. If you will EventMonitor is a centralized log file on steroids. As logging generates a lot of data, the system does clean up of outdated log events in the CMS database.For some scenarios you would like to do explicit cleanup, this is where
Remove-IshEvent
relying onEventMonitor25.DeleteByProgressId
comes in. Note that removing big amounts of data across the web services API is never the most performant solution. And the only API function for delete requires existing ProgressId identifiers to come in.IshEventsGroup
-IshEvent[]
that passes existing events, most likely generated byGet-IshEvent
and its filters-DeleteFailedEvent
, defaults to true-BusyFailedEvent
, defaults to trueParameterGroup
-ProgressId[]
, however ISHRemote respects pipeline objects and respects the CMS identifiers. And ProgressId is not considered stable API surface. SoIshEventsGroup
is preferably used.Workaround...
As the DeleteByProgressId call is quite simple, one could simply run the below using the WCF-SOAP proxies (probably ISHRemote v0.x only)
The text was updated successfully, but these errors were encountered: