Lines 1 - 25 are a utility method to trigger the Xots tasks, aggregate the output and post it to viewScope.
Lines 3 - 7 create a HashMap of the state key (e.g. FL for Florida) and names. This runs as the current user.
Line 10 creates a List to contain the Futures, each of which is a tasklet to kick off and wait for the response. The type for the Futures is set as a String.
Lines 11 - 14 iterate the HashMap and create a new UserLookup object, passing in the relevant state key and state name. The object is then passed to the Xots service and loaded into the List created on line 10. As we'll see later, the result of the tasklet is a String. Ten will run at any one time, the others sitting in the queue to start as and when a Xots thread is available.
Line 17 creates a TreeSet. Using a TreeSet enables the results to be sorted alphabetically, because each String will start with the state name. This needs to be done because although the threads are kicked off in state order, they may not complete in state order. Some may complete quicker than others.
Lines 18 - 20 iterate through the List of Futures and as and when a tasklet completes, it will be processed.
f.get() gets the result of the tasklet and, as we'll see later, that's a String.
Line 21 posts the TreeSet of Strings to the viewScope variable.
Lines 28 onwards are the Xots tasklet, in this case a Callable. Because we don't need access to any scoped variables or XPages runtime, we just extend the more limited
AbstractXotsCallable class. This still has access to the database etc required for error handling.
Line 27 sets the session as
Tasklet.Session.NATIVE which means the tasklet will run as the server. The context is set as
Context.DEFAULT, because no XPages scopes need passing into the tasklet.
Lines 29 and 30 declare two properties,
stateName_, to hold the state key and state name.
Lines 32 - 35 store the variables passed into the properties of this object. This means that they can be used in the