Abstract: A method of verifying, during a continuous integration (CI) and continuous delivery (CD) process, that an asynchronous message contract between a consumer service and a provider service in a microservice architecture has not been broken by a change to the provider service is disclosed. The asynchronous message contract is retrieved from a central server. A test message queue is created, the test message queue being separate from an existing message queue. Generation of a message based on a precondition specified in the asynchronous message contract is triggered. The message is retrieved from the test queue. The message is verified according to the asynchronous message contract, the verifying based on a build error not being generated during the CI and CD process.

Abstract: Embodiments facilitate efficient and flexible handling of metadata for processing in a microservice architecture (MSA) environment. A consumer service and a provider service both utilize a data model having metadata. A central repository stores metadata information that is being called for by a consumer service. A dedicated meta service manages the metadata repository by listening to a message queue to obtain model-relevant metadata information from a provider service. That model-relevant metadata information may be static in nature, or may be dynamic (e.g., varying as between different tenants). The meta service recognizes the static/dynamic nature of the model-relevant metadata information (e.g., based upon content such as a tenant ID or other information) in a message from the provider service, and stores the metadata accordingly. Once stored in the central repository, the model-relevant metadata information may be communicated directly to the consumer service.

Abstract: Embodiments facilitate efficient and flexible handling of metadata for processing in a microservice architecture (MSA) environment. A consumer service and a provider service both utilize a data model having metadata. A central repository stores metadata information that is being called for by a consumer service. A dedicated meta service manages the metadata repository by listening to a message queue to obtain model-relevant metadata information from a provider service. That model-relevant metadata information may be static in nature, or may be dynamic (e.g., varying as between different tenants). The meta service recognizes the static/dynamic nature of the model-relevant metadata information (e.g., based upon content such as a tenant ID or other information) in a message from the provider service, and stores the metadata accordingly. Once stored in the central repository, the model-relevant metadata information may be communicated directly to the consumer service.

Abstract: A method of verifying, during a continuous integration (CI) and continuous delivery (CD) process, that an asynchronous message contract between a consumer service and a provider service in a microservice architecture has not been broken by a change to the provider service is disclosed. The asynchronous message contract is retrieved from a central server. A test message queue is created, the test message queue being separate from an existing message queue. Generation of a message based on a precondition specified in the asynchronous message contract is triggered. The message is retrieved from the test queue. The message is verified according to the asynchronous message contract, the verifying based on a build error not being generated during the CI and CD process.

Abstract: A method of verifying, during a continuous integration (CI) and continuous delivery (CD) process, that an asynchronous message contract between a consumer service and a provider service in a microservice architecture has not been broken by a change to the provider service is disclosed. The asynchronous message contract is retrieved from a central server. A test message queue is created, the test message queue being separate from an existing message queue. Generation of a message based on a precondition specified in the asynchronous message contract is triggered. The message is retrieved from the test queue. The message is verified according to the asynchronous message contract, the verifying based on a build error not being generated during the CI and CD process.

Abstract: A method of verifying, during a continuous integration (CI) and continuous delivery (CD) process, that an asynchronous message contract between a consumer service and a provider service in a microservice architecture has not been broken by a change to the provider service is disclosed. The asynchronous message contract is retrieved from a central server. A test message queue is created, the test message queue being separate from an existing message queue. Generation of a message based on a precondition specified in the asynchronous message contract is triggered. The message is retrieved from the test queue. The message is verified according to the asynchronous message contract, the verifying based on a build error not being generated during the CI and CD process.

Abstract: A method of verifying, during a continuous integration (CI) and continuous delivery (CD) process, that an asynchronous message contract between a consumer service and a provider service in a microservice architecture has not been broken by a change to the provider service is disclosed. The asynchronous message contract is retrieved from a central server. A test message queue is created, the test message queue being separate from an existing message queue. Generation of a message based on a precondition specified in the asynchronous message contract is triggered. The message is retrieved from the test queue. The message is verified according to the asynchronous message contract, the verifying based on a build error not being generated during the CI and CD process.

Abstract: A method of verifying, during a continuous integration (CI) and continuous delivery (CD) process, that an asynchronous message contract between a consumer service and a provider service in a microservice architecture has not been broken by a change to the provider service is disclosed. The asynchronous message contract is retrieved from a central server. A test message queue is created, the test message queue being separate from an existing message queue. Generation of a message based on a precondition specified in the asynchronous message contract is triggered. The message is retrieved from the test queue. The message is verified according to the asynchronous message contract, the verifying based on a build error not being generated during the CI and CD process.

Abstract: Embodiments of the present disclosure may provide a system and method for processing an online transactional processing (OLTP) transaction on a column-based storage of a database. The method may include receiving a request of the OLTP transaction to access data on the column-based storage. A determination may be made whether a cache associated with the database includes column information for the OLTP transaction. If the cache includes the column information for the OLTP transaction, the method may include processing the OLTP transaction with the column information in the cache. If the cache does not include the column information for the OLTP transaction, the method may include selecting columns from the column-based storage of the database.

Abstract: A method comprises: executing an executable code by a computer processor; repetitively executing at least a portion of the executable code comprising dynamic memory allocation requests and dynamic memory deallocation requests, wherein a repetition number of the repetitive executions is an integer value greater than one; in response to execution of each of the dynamic memory allocation requests generating a record, each of the records comprising a unique memory identification of the main memory dynamically allocated upon the execution of the each of the dynamic memory allocation requests and a unique code identification of a fragment of the executable code and/or of a fragment of a source code corresponding to the fragment of the executable code.

Abstract: Systems and methods are described for converting business logic architecture from a native language (e.g., processor compiled code) into a scripting language (e.g., scripted code) for software as a service (SaaS) delivery methods for enterprise resource planning. The systems and methods may include generating a plurality of business process patterns representing business logic associated with one or more of a plurality of business objects, obtaining a plurality of code portions that correspond to one or more of the plurality of business process patterns, the plurality of code portions being coded in a scripting language and stored in a script repository, defining at least one extension point for each business process pattern. Each extension point may represent an interface, within the business logic, in which to insert one or more of the plurality of code portions into processor-compiled architecture in a software application.

Abstract: Systems and methods are described for converting business logic architecture from a native language (e.g., processor compiled code) into a scripting language (e.g., scripted code) for software as a service (SaaS) delivery methods for enterprise resource planning. The systems and methods may include generating a plurality of business process patterns representing business logic associated with one or more of a plurality of business objects, obtaining a plurality of code portions that correspond to one or more of the plurality of business process patterns, the plurality of code portions being coded in a scripting language and stored in a script repository, defining at least one extension point for each business process pattern. Each extension point may represent an interface, within the business logic, in which to insert one or more of the plurality of code portions into processor-compiled architecture in a software application.

Abstract: A method comprises: executing an executable code by s computer processor; repetitively executing at least a portion of the executable code comprising dynamic memory allocation requests and dynamic memory deallocation requests, wherein a repetition number of the repetitive executions is an integer value greater than one; in response to execution of each of the dynamic memory allocation requests generating a record, each of the records comprising a unique memory identification of the main memory dynamically allocated upon the execution of the each of the dynamic memory allocation requests and a unique code identification of a fragment of the executable code and/or of a fragment of a source code corresponding to the fragment of the executable code.

Abstract: Embodiments of the present disclosure may provide a system and method for processing an online transactional processing (OLTP) transaction on a column-based storage of a database. The method may include receiving a request of the OLTP transaction to access data on the column-based storage. A determination may be made whether a cache associated with the database includes column information for the OLTP transaction. If the cache includes the column information for the OLTP transaction, the method may include processing the OLTP transaction with the column information in the cache. If the cache does not include the column information for the OLTP transaction, the method may include selecting columns from the column-based storage of the database.