Why Special Steps Are Required for Disconnected Mode
Some examples help to clarify the reason for, and the workings of, steps that are executed only in disconnected mode.
The basic upload of data from the inventory beacon to the operations database is not disrupted by disconnected mode: the inventory beacon has special services to ensure than gathered inventory is uploaded at appropriate times.
However, there are other common scenarios for inventory adapters that are disrupted. Consider this algorithm, designed to optimize data gathering and upload in connected mode by only collecting differential inventory (inventory that has changed since last collection):
Logical step described | Step type |
---|---|
Create a temporary table #KnownComputer on the source, to
hold IDs of previously inventoried computers and last known updated
date. |
ExecuteOnSource |
Send the result of a SELECT statement on the target
database, listing previously inventoried computer IDs and last known updated
date, into the temporary table #KnownComputer on the source
database. |
TargetToSource |
Source queries join against the temporary table
#KnownComputer to optimise their returned
results. |
ExecuteOnSource |
This works well in connected mode, and only new/changed inventory records are uploaded when this sequence is executed.
However, in disconnected mode, all TargetToSource steps are
disabled, leaving the #KnownComputer
temporary table empty. Following
steps that attempt joins against the empty table fail, and no inventory is returned.
We therefore need an alternative step, available in disconnected mode only, to prevent the failure and allow reuse of all the other procedure steps so that inventory is returned. In disconnected mode, it is not possible to select content from the target database; but we can take a different action to prevent the temporary table sitting empty.
Logical step described | Step type | Disconnected | Runs in which modes |
---|---|---|---|
Create a temporary table #KnownComputer on the source, to
hold IDs of previously inventoried computers and last known updated
date. |
ExecuteOnSource | Check box clear | Connected/Disconnected |
Send the result of a SELECT statement on the target
database, listing previously inventoried computer IDs and last known updated
date, into the temporary table #KnownComputer on the source
database. |
TargetToSource | Check box ignored | Connected only |
Enforce full import by filling in #KnownComputer with all
current IDs in the source system. |
ExecuteOnSource | Check box set | Disconnected only |
Source queries join against the temporary table
#KnownComputer to optimise their returned
results. |
ExecuteOnSource | Check box clear | Connected/Disconnected |
We can see that the single extra step allows us to use the adapter in both connected and disconnected modes. In connected mode, it performs a differential inventory. In disconnected mode where differential inventory is not possible, it substitutes a full inventory.
FlexNet Manager Suite (On-Premises)
2022 R1