A method and related system to concurrently process a temporal message stream. The method comprises obtaining messages of a message stream, each message having an associated timestamp. The method further comprises storing each message in at least one of a plurality of queues, wherein the messages of each queue are ordered based on their timestamp such that a message with the earliest timestamp is positioned at the front of the queue. The method then comprises controlling retrieval of the target message from the front of a target queue based on a timing difference between the timestamp of the message and the timestamps of the front message of each of the other queues of the plurality of queues.

An apparatus in one embodiment comprises at least one processing platform comprising a plurality of processing devices. The at least one processing platform is configured to provide a plurality of applications with centralized access to a plurality of message oriented middleware (MOM) servers via a connectivity layer, to establish a connection between a given one of the plurality of applications and a given one of the plurality of MOM servers via the connectivity layer, and to exchange data between the given one of the plurality of applications and the given one of the plurality of MOM servers via the connectivity layer.

In a distributed system with a microservice architecture having a plurality of services and a messaging layer for communication therebetween, systems and methods include receiving messages from a first service to a second service in the messaging layer; queuing responses from the messages; and utilizing one or more bulk messaging techniques to send the responses back to the first service from the second service. The systems and methods can also include maintaining statistics related to the one or more bulk messaging techniques; and automatically determining which of the one or more bulk messaging techniques based on the statistics, to minimize latency of the messaging layer.

Methods, systems, and computer programs are directed to the implementation of configurable hierarchical schedulers with multiple levels, where each level may use one of several types of queueing mechanisms. A configurable, hierarchical scheduler is designed to handle large scale processing of requests (e.g., transmitting outgoing messages). The hierarchical scheduler distributes the loads to different queues handling different types of messages (e.g., by user ID, by Internet Address (IP), by schedule). The different layers of the hierarchical scheduler are configurable to queue and schedule traffic based on many factors, such as IP address, handling reputation, available downstream bandwidth, fairness, concurrency rates to handle multiple constraints, scheduling per client, time of delivery constrains, rate limits per user, domain scheduling per user, concurrency throttling per outbound channel, and sharing global rate limits across service processors.

Systems and methods described herein provide for management of notifications. A computing device in communication with a client device receives a notification from at least one notification source. The notification may be for rendering on a screen at the client device. A policy engine of the computing device may identify a context of the notification. The policy engine may add a tag to the notification according to the identified context to control rendering of the notification at the client device. The computing device may transmit the notification with the tag to a notification service at the client device. The notification service may be configured to manage the notification at the client device in accordance with the tag.

A system includes persistent storage configured to store definitions of interfaces of remote software applications, and a software application configured to define the interfaces. The software application identifies a remote software application system by which the remote software applications are exposed for execution, and obtains therefrom a specification of a particular remote software application. The software application determines, based on the specification, (i) objects accessible by way of the particular remote software application and (ii) functions invokable to interact with the objects. The software application generates actions that define an interface for the particular remote software application. Each action is configured to invoke execution of one or more of the functions by transmitting a request to the remote software application system and, in response, receive, by way of the remote software application system, an output of the one or more of the functions. The actions are stored in the persistent storage to define the interface.

Capacity-based scaling of queue-based resources is described. Initially, a scaling system measures capacity of service processors that are instantiated at a cloud computing service system to provide a service on behalf of a service provider, and also measures a load on these processors. In contrast to conventional scaling systemswhich base scalings on a number of queued messages which the instantiated service processors process to provide the servicethe scaling system measures the load in terms of not only the number of messages held in a queue but also an input rate of the messages to the queue. The described scaling system then determines whether and by how much to scale the instantiated processors based on this number of messages and input rate. Given this, the scaling system instructs the cloud computing service system how to scale the instantiated service processors to provide the service.

A processor implemented method for monitoring the performance of a message queue for communication between processes is described. The method includes, by an initiating process, publishing a trigger message to a first topic in the message queue, wherein the trigger message identifies one or more performance metrics and at least two processes that communicate via the message queue. The method further includes, by one or more of the at least two processes, retrieving the trigger message from the first topic in the message queue; performing a measurement on one or more messages exchanged between the processes over the message queue, wherein the measurement determines the one or more performance metrics; and publishing the one or more determined performance metrics to a second topic in the message queue. The method also includes, at a receiving process, retrieving the published performance metrics from the second topic in the message queue.

The system provides an event driven system that sits between the enterprise ecosystem and the client system. The system creates a bridge between systems that produce actionable information and systems that consume events related to that information. It coordinates data-change events between those internal microservices for the client, providing a simple, well-typed interface for change events that may drive downstream actions in a consuming service. In one embodiment, the system can intercept those messages, decorate them with client-specific configuration data, and send them to the appropriate downstream client systems, all the while tracking the state of events to provide an auditable window into the system. Events are designed to help an appropriately credentialed and authorized consuming system dynamically call the enterprise's API resources in post-processing by providing relative linking as an out-of-the-box attribute of the event messages.

Methods and systems for enhanced data reliability for sensor devices, such as Internet of Things (IoT) sensors can include a first set of sensor devices (e.g., primary sensors) for collecting data in accordance with an application program. A second set of sensor devices (peer sensors) can be enabled for collecting supplemental data. Each of the sensor devices in the second set of sensor devices corresponds to one of the sensor devices in the first set of sensor devices. After receiving data from a selected sensor device of the set of first sensor devices and determining that the received data triggers a notification for a critical event, a second sensor of the second set of sensor devices can be interrogated to confirm the critical event. The event is confirmed by a convergence of data from the selected sensor device and the supplemental data from the second sensor device.