Abstract: Embodiments provide systems and methods for a generic representational state transfer (ReST) framework that can be used to communicate with heterogeneous ReST interfaces. On embodiment of a method comprises storing endpoint configurations for heterogeneous ReST interfaces as configurable files consumable by a ReST framework; receiving, by the ReST framework, a request to perform an operation and ReST resource details associated with the request to perform the operation; generating a ReST request, the ReST request including an endpoint URL for a target resource, a Hypertext Transfer Protocol (HTTP) method, and a header; and sending the ReST request to a ReST server. Generating the ReST request can comprise accessing the first endpoint configuration and extract first endpoint configuration data that is applicable to servicing the request to perform the operation, the first endpoint configuration data specifying the header; and mapping the operation to the HTTP method.

Abstract: Disclosed is a new identifier allocation approach for allocating repository object identifiers beyond a maximum number usually allowed for a single repository. The new identifier allocation approach includes an enhanced identifier structure in which a portion usually reserved for a docbase identifier is modified to combine with a partition identifier. The actual docbase identifier is stored in a server configuration file. When the maximum number of object identifiers has been allocated, a new partition is created and a sequence table is updated with a new entry that reflects the new partition. A new repository object identifier is allocated using the docbase identifier combined with the new partition identifier. In this way, more than 4 billion objects per object type can be addressed uniquely within a docbase by creating new partitions. This new approach is very unique and flexible in accommodating both on premises and multi-tenant environments.

Abstract: The disclosure provides a new content server framework in which functionalities of a content server are implemented as lightweight microservices. At startup of the content server framework, a content server container and a set of microservices are launched. The content server container only has a content server application programming interface (API) which has a controller that can instantiate controller applications, each having a master module and worker(s). When a request is received, the content server API routes it to an appropriate microservice which stores the request in a repository. The master module retrieves the request from the repository and places it in a queue. The worker picks up the request from the queue and processes it. The controller keeps track of details of each controller application container that it instantiated (e.g., load and status) and automatically scale up or down the number of instances.

Abstract: Embodiments of a multitenant content server that employs embodiments of a database architecture for use in multitenant environments that includes a global partition and a tenant partition for each tenant. These partitions can be accessed using sessions corresponding to the partitions and interfaces associated with the tenants.

Abstract: Embodiments of a multitenant content server that employs embodiments of a database architecture for use in multitenant environments that includes a global partition and a tenant partition for each tenant. These partitions can be accessed using sessions corresponding to the partitions and interfaces associated with the tenants.

Abstract: The disclosure provides a new content server framework in which functionalities of a content server are implemented as lightweight microservices. At startup of the content server framework, a content server container and a set of microservices are launched. The content server container only has a content server application programming interface (API) which has a controller that can instantiate controller applications, each having a master module and worker(s). When a request is received, the content server API routes it to an appropriate microservice which stores the request in a repository. The master module retrieves the request from the repository and places it in a queue. The worker picks up the request from the queue and processes it. The controller keeps track of details of each controller application container that it instantiated (e.g., load and status) and automatically scale up or down the number of instances.

Abstract: A configuration object is provided to configure a server. The configuration object has an associated type to which the configuration object applies and information about a plurality of file stores available to the server. A method for data access can include, receiving, by the server, a request to perform a first operation with respect to a content object associated with the associated type to which the configuration object applies, using the configuration object to determine, from the plurality of file stores available to the server, a set of candidate file stores to service the request, and selecting a target file store from the set of candidate file stores and servicing the request using the target file store. Selecting the target file store includes mapping the object identifier to the target file store.

Abstract: The disclosure provides a new content server framework in which functionalities of a content server are implemented as lightweight microservices. At startup of the content server framework, a content server container and a set of microservices are launched. The content server container only has a content server application programming interface (API) which has a controller that can instantiate controller applications, each having a master module and worker(s). When a request is received, the content server API routes it to an appropriate microservice which stores the request in a repository. The master module retrieves the request from the repository and places it in a queue. The worker picks up the request from the queue and processes it. The controller keeps track of details of each controller application container that it instantiated (e.g., load and status) and automatically scale up or down the number of instances.

Abstract: A configuration object is provided to configure a server. The configuration object can include storage node information for a first set of storage nodes available to a server. The configuration object determines, from the storage node information, a second set of storage nodes for inclusion in a map. The configuration object maps each storage node in the second set of storage nodes to a different index value in a set of index values. The configuration object receives an object identifier for a first object, transforms the object identifier into a resulting index value in the set of index values and, based on a determination that a first storage node is mapped to the resulting index value in the map, selects the first storage node as a target storage node for servicing a request to perform a first operation with respect to the first object.

Abstract: Disclosed is a new identifier allocation approach for allocating repository object identifiers beyond a maximum number usually allowed for a single repository. The new identifier allocation approach includes an enhanced identifier structure in which a portion usually reserved for a docbase identifier is modified to combine with a partition identifier. The actual docbase identifier is stored in a server configuration file. When the maximum number of object identifiers has been allocated, a new partition is created and a sequence table is updated with a new entry that reflects the new partition. A new repository object identifier is allocated using the docbase identifier combined with the new partition identifier. In this way, more than 4 billion objects per object type can be addressed uniquely within a docbase by creating new partitions. This new approach is very unique and flexible in accommodating both on premises and multi-tenant environments.

Abstract: Embodiments of a multitenant content server that employs embodiments of a database architecture for use in multitenant environments that includes a global partition and a tenant partition for each tenant. These partitions can be accessed using sessions corresponding to the partitions and interfaces associated with the tenants.

Abstract: Disclosed is a new identifier allocation approach for allocating repository object identifiers beyond a maximum number usually allowed for a single repository. The new identifier allocation approach includes an enhanced identifier structure in which a portion usually reserved for a docbase identifier is modified to combine with a partition identifier. The actual docbase identifier is stored in a server configuration file. When the maximum number of object identifiers has been allocated, a new partition is created and a sequence table is updated with a new entry that reflects the new partition. A new repository object identifier is allocated using the docbase identifier combined with the new partition identifier. In this way, more than 4 billion objects per object type can be addressed uniquely within a docbase by creating new partitions. This new approach is very unique and flexible in accommodating both on premises and multi-tenant environments.

Abstract: Embodiments of a multitenant content server that employs embodiments of a database architecture for use in multitenant environments that includes a global partition and a tenant partition for each tenant. These partitions can be accessed using sessions corresponding to the partitions and interfaces associated with the tenants.

Abstract: The disclosure provides a new content server framework in which functionalities of a content server are implemented as lightweight microservices. At startup of the content server framework, a content server container and a set of microservices are launched. The content server container only has a content server application programming interface (API) which has a controller that can instantiate controller applications, each having a master module and worker(s). When a request is received, the content server API routes it to an appropriate microservice which stores the request in a repository. The master module retrieves the request from the repository and places it in a queue. The worker picks up the request from the queue and processes it. The controller keeps track of details of each controller application container that it instantiated (e.g., load and status) and automatically scale up or down the number of instances.

Abstract: A method comprising communicating with a server to store first content, communicating with the server comprising: establishing a first plurality of content transfer sessions with the server to transfer the first plurality of content chunks to the server for storage in the distributed data store as associated content of an object, including establishing at least two parallel content transfer sessions to transfer at least two of the content chunks from the first plurality of content chunks to the server in parallel; and transferring each content chunk from the first plurality of content chunks and chunk metadata for that content chunk to the server using a corresponding content transfer sessions from the first plurality of content transfer sessions, the chunk metadata including the chunk id for that chunk and an indication of the object to which the chunk is to be stored.