Abstract: Metadata-based parsing generates a schema that is used to ingest data from an incoming object. Embodiments extend metadata-based parsing to support changes to a generated schema based on the lifecycle of the object. A schema of an incoming data object is compared with existing schema (if any) to determine differences therebetween. Detection of minor differences reveals mere evolution of an existing data object, triggering adjustment of the existing schema (e.g., to ?add a new field, ?deprecate an existing field, ?change a format of an existing field, and/or ?delete an existing field). Detection of more substantive differences from an existing schema can result in more substantive changes being made according to stored logic. Embodiments improve system operation by conserving effort and cost that would otherwise be consumed to perform metadata-based parsing and data ingestion of all incoming objects, regardless of their similarity to existing schema.

Abstract: Embodiments relate to metadata-based generic parsing of an incoming data object to transform it for different purposes, such as conversion into a format more suitable for a specific storage type. The received data object comprises members organized according to a structure, each member containing data. The object's structure and the member's type are defined by the associated metadata. The metadata is referenced by parsing logic to generate a schema representing the structure of the data object in a different format (such as an ER table schema). The schema is then stored. When data is received, the metadata is referenced to parse the corresponding object's data accordingly and for ingestion into the generated schema and storage.

Abstract: Compliancy management is implemented across a plurality of applications utilizing a generic model. The generic compliancy model includes references to external data objects. A compliancy state record for each data object records a current compliancy status (e.g., active, inactive, blocked, deleted, incompliant). That status may transition in response to the receipt of an incoming compliancy event that is processed according to a rule set. The compliancy state record is associated with one or more compliancy object records storing data of the external data object. The generic structure of the compliancy model is agnostic to specific application data models of the services, thereby offering benefits of scalability that are compatible with modern microservice-based architectures.

Abstract: A user interface is presented that allows a user to enter data for a product costing structure. The product costing structure contains data for one or more component items of the product. Based on a database that stores other product costing structures, the data of the product costing structure is validated and one or more informational messages are presented on the user interface. Multiple plausibility checks are realized as separate functions. Each of the separate functions approves the data as being plausible or produces a message indicating an implausibility of the data. The product structure may be a hierarchical structure that consists of items of a product. A plausibility check may be performed on the hierarchical relationship of the items. A plausibility check may be performed to determine if scalar values in the product costing structure are within a plausible range.