Shared service points in ECS

Library staff have the ability to view all requests made at a selected service point through the Requests UI App, and to generate and print various slips (such as search slips, pickup slips, etc.). How does this work?

The service point (selected in the top right corner) can be designated as the primary service point for one or more Locations. Subsequently, these Locations are used as effective locations for items, and the item ID, in turn, is stored in each request.

Thus, there's a straightforward and comprehensible connection between the service point and the request, making it easy to trace. The figure below illustrates this connection.

However, in the case of ECS, this connection is disrupted. Specifically, when crossing the tenant boundary line, the connection between service points and locations is lost.

Important note: this discussion pertains to an ECS setup where there exists a shared, central catalog of instances in the central tenant, while holdings and items are stored in other so-called data tenants.

To safely cross this tenant boundary line and restore the connection, there are two possible solutions: either make locations or service points shared. In this context, "shared" means that tenants must have a common list of entities with the same identifiers, names, etc.

Let's take a look at this diagram: on the left, the diagram presents the option with shared locations, while on the right, it shows shared service points.

During the analysis of options, it was discovered that locations are involved in the functionality of central ordering. It was also decided that it can be assumed that the number of service points is significantly less than the number of locations (at least for LC). As a result of several discussion sessions, it was decided to proceed with shared service points.