Abstract: An example operation may include one or more of receiving a database storage request at a decentralized database, executing an operation of the database storage request at a database node based on chaincode to generate a simulated result without committing the database storage request to the decentralized database, determining whether the chaincode of the database node is valid via a functional testing that is performed based on an output of the execution of the database storage request, and, in response to determining the chaincode is valid, endorsing the database storage request for storage at the decentralized database and transmitting the endorsement to one or more database nodes of the decentralized database.

Abstract: Validating push messages can include, responsive to receiving a push message intended for delivery to a recipient, storing, using a processor, the push message within an approval queue, sending, using the processor, a message including content of the push message to a reviewing device of a reviewing user, and receiving, using the processor, a reply from the reviewing device. The push message can be selectively provided, using the processor, from the approval queue to a push message delivery system based upon whether the reply indicates approval of the content of the push message.

Abstract: Validating push messages can include, responsive to receiving a push message intended for delivery to a recipient, storing, using a processor, the push message within an approval queue, sending, using the processor, a message including content of the push message to a reviewing device of a reviewing user, and receiving, using the processor, a reply from the reviewing device. The push message can be selectively provided, using the processor, from the approval queue to a push message delivery system based upon whether the reply indicates approval of the content of the push message.

Abstract: Provided are techniques for synchronizing a device using push notifications. For each of a plurality of messages, a message record is created in a table of a database with a message create time for a message, a device identifier of a device to receive the message, an application identifier of an application on the device to receive the message, message content of the message, and an indicator to indicate whether the message has been picked up by the device. A message is selected from the plurality of messages. It is determined that a message retry count for the message has not been met and the message has not been picked up by the device. It is determined that it is time to retry sending a silent push notification based on a retry interval. The silent push notification is sent to the application on the device to wake up the application.

Abstract: Provided are techniques for synchronizing a device using push notifications. For each of a plurality of messages, a message record is created in a table of a database with a message create time for a message, a device identifier of a device to receive the message, an application identifier of an application on the device to receive the message, message content of the message, and an indicator to indicate whether the message has been picked up by the device. A message is selected from the plurality of messages. It is determined that a message retry count for the message has not been met and the message has not been picked up by the device. It is determined that it is time to retry sending a silent push notification based on a retry interval. The silent push notification is sent to the application on the device to wake up the application.

Abstract: An example operation may include one or more of receiving a database storage request at a decentralized database, executing an operation of the database storage request at a database node based on chaincode to generate a simulated result without committing the database storage request to the decentralized database, determining whether the chaincode of the database node is valid via a functional testing that is performed based on an output of the execution of the database storage request, and, in response to determining the chaincode is valid, endorsing the database storage request for storage at the decentralized database and transmitting the endorsement to one or more database nodes of the decentralized database.

Abstract: A process for determining a problematic condition while running software includes: loading a first pattern data set into a volatile memory of a computer, with the first pattern data set being associated with a set of problematic conditions, determining that a runtime symptom code generated while running software on the computer matches a pre-defined symptom code in a set of pre-defined symptom codes, collecting information during runtime according to a set of data collection instructions as a set of collected data, and determining, by applying a set of logic data to the set of collected data, a first problematic condition of the set of problematic conditions triggered the runtime symptom code.

Abstract: According to one embodiment, a method, computer system, and computer program product for directing an update of a mobile application based on one or more modules chosen by a user is provided. An embodiment may include receiving a user module preference for the mobile application based on a user input, may also include storing the received user module preference in a database, may include receiving an update for one or more modules within the mobile application from an administrator of the mobile application, and may also include transmitting the received update for the mobile application to one or more user devices based on the received user module preference.

Abstract: In a system for providing data and/or computational services, various resources are assigned a sort of points (called vouchers or IOUs) for work manager threads that are currently queued at each resource. When a resource (and its associated resource manager) has a relatively small queue, whereby the resource is holding a relatively small number of points, that resource will be assigned work manager threads for incoming services requests at a high preference, or priority. In this way, faster performing resources can more reliably be supplied with new requests, while relatively slow performing resources will tend not to unduly tie up limited work manager threads in long queues at the slow resources.

Abstract: In a system for providing data and/or computational services, various resources are assigned a sort of points (called vouchers or IOUs) for work manager threads that are currently queued at each resource. When a resource (and its associated resource manager) has a relatively small queue, whereby the resource is holding a relatively small number of points, that resource will be assigned work manager threads for incoming services requests at a high preference, or priority. In this way, faster performing resources can more reliably be supplied with new requests, while relatively slow performing resources will tend not to unduly tie up limited work manager threads in long queues at the slow resources.

Abstract: An apparatus, method, and system for receiving a request for a transaction using a computer system. An absence of a first identification of an application on a first user device is determined, when a beacon of the computer system does not detect the first identification within a defined geographical area. A plurality of transaction data from a transaction device is received. A second identification based on the received transaction data is generated. An installation status of the application on the first user device based on the generated second identification and the absence of the first identification is also generated.

Abstract: A process for determining a problematic condition while running software includes: loading a first pattern data set into a volatile memory of a computer, with the first pattern data set being associated with a set of problematic conditions, determining that a runtime symptom code generated while running software on the computer matches a pre-defined symptom code in a set of pre-defined symptom codes, collecting information during runtime according to a set of data collection instructions as a set of collected data, and determining, by applying a set of logic data to the set of collected data, a first problematic condition of the set of problematic conditions triggered the runtime symptom code.

Abstract: A process for determining a problematic condition while running software includes: loading a first pattern data set having a symptom code module, a problematic condition determination module, and a set of responsive action module(s), generating a runtime symptom code in response to a first problematic condition being caused by the running of the software on the computer, determining that the runtime symptom code matches a symptom code corresponding to the first pattern data set, determining that the first problematic condition caused the generation of the runtime symptom code, and taking a responsive action from a set of responsive action(s) that corresponds to the first problematic condition.

Abstract: Validating push messages can include, responsive to receiving a push message intended for delivery to a recipient, storing, using a processor, the push message within an approval queue, sending, using the processor, a message including content of the push message to a reviewing device of a reviewing user, and receiving, using the processor, a reply from the reviewing device. The push message can be selectively provided, using the processor, from the approval queue to a push message delivery system based upon whether the reply indicates approval of the content of the push message.

Abstract: Validating push messages can include, responsive to receiving a push message intended for delivery to a recipient, storing, using a processor, the push message within an approval queue, sending, using the processor, a message including content of the push message to a reviewing device of a reviewing user, and receiving, using the processor, a reply from the reviewing device. The push message can be selectively provided, using the processor, from the approval queue to a push message delivery system based upon whether the reply indicates approval of the content of the push message.

Abstract: An apparatus, method, and system for receiving a request for a transaction using a computer system. An absence of a first user identification of an application on a first user device is determined, when a beacon of the computer system does not detect the first user identification within a defined geographical area. A plurality of transaction data from a transaction device is received. A second user identification based on the received transaction data is generated. An installation status of the application on the first user device based on the generated second user identification and the absence of the first user identification is also generated.

Abstract: An apparatus, method, and system for receiving a request for a transaction using a computer system. An absence of a first identification of an application on a first user device is determined, when a beacon of the computer system does not detect the first identification within a defined geographical area. A plurality of transaction data from a transaction device is received. A second identification based on the received transaction data is generated. An installation status of the application on the first user device based on the generated second identification and the absence of the first identification is also generated.

Abstract: Embodiments of the present invention disclose an apparatus, method, and system for receiving a request for a transaction using a computer system. An absence of a first user identification of an application on a first user device is determined, when a beacon of the computer system does not detect the first user identification within a defined geographical area. A plurality of transaction data from a transaction device is received. A second user identification based on the received transaction data is generated. An installation status of the application on the first user device based on the generated second user identification and the absence of the first user identification is also generated.

Abstract: A process for determining a problematic condition while running software includes: loading a first pattern data set having a symptom code module, a problematic condition determination module, and a set of responsive action module(s), generating a runtime symptom code in response to a first problematic condition being caused by the running of the software on the computer, determining that the runtime symptom code matches a symptom code corresponding to the first pattern data set, determining that the first problematic condition caused the generation of the runtime symptom code, and taking a responsive action from a set of responsive action(s) that corresponds to the first problematic condition.

Abstract: A process for determining a problematic condition while running software includes: loading a first pattern data set having a symptom code module, a problematic condition determination module, and a set of responsive action module(s), generating a runtime symptom code in response to a first problematic condition being caused by the running of the software on the computer, determining that the runtime symptom code matches a symptom code corresponding to the first pattern data set, determining that the first problematic condition caused the generation of the runtime symptom code, and taking a responsive action from a set of responsive action(s) that corresponds to the first problematic condition.