The library calls outbound SCI methods when specific events occur. To receive these calls, you must configure a connection using createSciDestination(). Outbound SCI configuration has a protocol option that allows http or https. If the protocol is https, the library includes a WS-Security username and password token in the SOAP header to the outbound SCI destination. If the protocol is http, the library does not send a username and password token as it would be visible in clear text.
The library will make calls to the destination until you delete or disable the connection. Outbound methods are grouped by EventCategory. You can configure a destination to receive SCI calls for one, several, or all categories.
If communication with the destination is disrupted, the library will queue the calls for the retentionTimeLimit
specified for the destination. The time period is limited because of available space. This is intended to deal with temporary network outages, not as a means to have the library retain history for later delivery. If the library cannot connect to a SCI destination it retains un-sent events up to retentionTimeLimit
. Later, if the library can communication with the destination, it will send all unsent events in the order they occurred. If the library cannot communicate with the detestation within retentionTimeLimit
, the library discards all unsent and new events until communication is restored.
Outbound methods only specify input parameters, which are the data objects sent from the library to the called SCI service. The library does not expect a response from any of the methods except for ping(), which must return a string indicating success.
Sends a notification when a physical audit (scan of barcodes) completes.
Category: LIBRARY
Inputs: AuditEventDataDto
Sends a notification when the licensed capacity of the library complex changes.
Category: LIBRARY
Sends a notification when a CAP closes and the audit completes.
Category: CAP
Inputs: CapMoveEventDataDto
Sends a notification when the ownership of the CAP has been forcibly removed from a partition (usually by using forceFreeCap()).
Category: CAP
Inputs: CapOwnerOverriddenEventDataDto
Sends a notification when you need to open a CAP. The library sends this call when ejectExpiredCleaningCartridges, ejectCartridges, or continueEject processes require the operator to open the CAP.
Category: CAP
Inputs: CapReadyToOpenEventDataDto
Sends data about a device when its control state changes. This is usually for a device coming online or going offline, though some device types may have other states.
Category: DEVICE
Inputs: DeviceEventDataDto
Sends data when a device fails. Typically, the library also sends an ASR for the failure.
Category: DEVICE
Inputs: DeviceEventDataDto
Sends data when a devices is installed into the library. Only sent when a device is installed while the library is operating.
Category: DEVICE
Inputs: DeviceEventDataDto
Sends data when you remove a device from the library. Typically, the library only makes this call for a FRU because you must power off the library to remove most other devices.
Category: DEVICE
Inputs: DeviceEventDataDto
Sends a notification when a door closes and the audit completes.
Category: DOOR
Inputs: DoorEventDataDto
Sends a notification when a drive reports that it needs cleaning by an application. The library does not send this call if library auto-cleaning is enabled.
Category: CLEANING_REQUIRED
Inputs: DriveCleanNeededEventdataDto
Sends data about an alert condition. Alerts are conditions in the library that require intervention. Generally, the library also sends ASRs or SNMP traps. Over temp events might trigger an alert. Not all alerts are device failures, but all device failures are alerts.
Category: DEVICE
Inputs: FaultEventDataDto
Sends data about the library complex when the library complex's functional state (such as normal or fault) or control state (online, offline) changes.
Category: LIBRARY
Inputs: LibraryComplexEventDataDto
Sends data about a library when the library's functional state (such as normal or fault) or control state (online, offline) changes.
Category: LIBRARY
Inputs: LibraryEventDataDto
Sends a notification whenever the library identifies a "lost" cartridge. Lost cartridges can occur when the library finds a cartridges, but the library cannot determine the proper location for the cartridge.
Category: LIBRARY
Inputs: LostCartridgesEventDataDto
Sends a notification for any cartridge move.
Category: CARTRIDGE_MOVEMENT
Inputs: CartridgeMoveEventDataDto
Sends a notification one minute after media validation starts and then every 10 minutes. This call can also be made available for normal (non media validation) mounts.
Category: MEDIA_VALIDATION
Sends a notification when the media validation drive pool changes. The call returns one element for each drive in the media validation pool.
Category: MEDIA_VALIDATION
Inputs: List of MediaValidationDrivePoolModifiedEventDataDto
Sends a notification when a partition changes. Generally, any partitioning changes involve at least two partitions, because the commands that change partitions move cells and drives from one partition to another.
Category: PARTITION
Inputs: List of PartitionEventDataDto for affected partitions
The library calls ping() when an outbound SCI destination is created to verify connectivity. The library passes in a string containing the library's hostname. The ping() method should return a string indicating success that will be appended into the library logs.
Category: None
Inputs: String
Sends data about a rail when the rail's functional state changes (such as normal or fault).
Category: LIBRARY
Inputs: RailEventDataDto
Sends a test event to verify connectivity after a call to createTestEvent().
Category: TEST
Inputs: TestEventDataDto