Abstract: A trace anomaly grouping and visualization technique logically groups traces with anomalies to cases to enable software developers to monitor, diagnose and visualize the anomalies, as well as to solve the anomalies during application development and production. A client library of an investigative platform collects signals from traces (trace signal information). The technique organizes (groups) related trace signals of methods with anomalies (e.g., exceptions, performance abnormalities such as slowness) into datasets (denominated as “cases”) based on common cause for an anomaly and correlates the signals to identify a case. The collected information may be used to differentiate between root causes of the anomalies using a comparative visualization of traces displayed on a standard user interface of the investigative platform.

Abstract: A dynamic configuration trace capture technique enables software developers to monitor, diagnose and solve errors associated with application development and production. A client library of an investigative platform is loaded in a user application and interacts with an agent process to instrument executable code of the user application. A dynamic configuration specifies information, such as methods and associated arguments, variables and data (values), to instrument. The client library may re-load the dynamic configuration at the capture points, which may change the frequency of tracing a method and its associated information. The dynamic configuration may be defined per method, argument, variable, and/or data structure. The dynamic configuration may be initially deployed with default heuristics defined in the client library.

Abstract: An investigative platform enables software developers to monitor and diagnose anomalies associated with application development and production. A client library interacts with a separate agent to instrument executable code of a user application. The client library transfers executable code and trace information captured from the user application to the agent to isolate the capture from the executing user application. The agent buffers, examines, and performs further processing (such as compression) on the captured traces, and sends the information as substantially compressed traces to an analysis and persistent storage (APS) infrastructure. A consumer service loads the information into a durable message queue for processing by stages of an analysis pipeline of the APS infrastructure. Processing by the stages of the analysis pipeline results in findings, such as trace amalgamation into cases.

Abstract: A dynamic library replacement technique enables replacement of original functions or methods of application libraries based on analysis of traces captured by a client library of an investigative platform. Traces captured from the user application are analyzed to identify the original methods of the user application that may be replaced by the client library. The original methods may be identified based on estimated performance improvements determined from the analysis of the captured traces. The improved method replacements and estimated performance improvements may be graphically presented to a user via a user interface (UI) infrastructure of the investigative platform. Replacement of the improved methods may be defined in the dynamic configuration or interactively via the UI infrastructure and continued performance monitoring reported. The specific performance for any method may be monitored along with a fidelity of the monitored method.

Abstract: An instrumentation trace capture technique enables software developers to monitor, diagnose and solve errors associated with application development and production. A client library of an investigative platform is loaded in a user application executing on a virtual machine instance of a virtualized computing environment. The client library interacts with an agent of the platform to instrument executable code of the user application and, to that end, loads a capture configuration that specifies, inter alia, methods and associated arguments, variables and data structures (values), to instrument. The client library inspects the executable code to determine portions of the code to instrument based on the capture configuration, which describes a degree of fidelity (e.g., a frequency) of the executable code and data to trace at runtime. Capture points of the runtime application are implemented as callbacks to the client library, which are registered with a runtime system executing the user application.

Abstract: An instrumentation overhead regulation technique regulates an amount of work performed by a client library of an investigative platform used to monitor, diagnose and solve errors associated with application development and production. The client library calculates processing resources utilized during its runtime activity to enable adjustment of the amount of work it performs based on the measured activity. An agent may determine the overhead activity impact to user application performance by monitoring processing resource metrics of the user application. The agent analyzes the calculated overhead and processing resource metrics to render decisions to automatically regulate the capture fidelity of the client library. Regulation of the capture fidelity may be implemented by modifying parameters of a dynamic configuration.

Abstract: An investigative platform enables software developers to monitor and diagnose anomalies associated with application development and production. A client library interacts with a separate agent to instrument executable code of a user application. The client library transfers executable code and trace information captured from the user application to the agent to isolate the capture from the executing user application. The agent buffers, examines, and performs further processing (such as compression) on the captured traces, and sends the information as substantially compressed traces to an analysis and persistent storage (APS) infrastructure. A consumer service loads the information into a durable message queue for processing by stages of an analysis pipeline of the APS infrastructure. Processing by the stages of the analysis pipeline results in findings, such as trace amalgamation into cases.

Abstract: A dynamic configuration trace capture technique enables software developers to monitor, diagnose and solve errors associated with application development and production. A client library of an investigative platform is loaded in a user application and interacts with an agent process to instrument executable code of the user application. A dynamic configuration specifies information, such as methods and associated arguments, variables and data (values), to instrument. The client library may re-load the dynamic configuration at the capture points, which may change the frequency of tracing a method and its associated information. The dynamic configuration may be defined per method, argument, variable, and/or data structure. The dynamic configuration may be initially deployed with default heuristics defined in the client library.

Abstract: A trace anomaly grouping and visualization technique logically groups traces with anomalies to cases to enable software developers to monitor, diagnose and visualize the anomalies, as well as to solve the anomalies during application development and production. A client library of an investigative platform collects signals from traces (trace signal information). The technique organizes (groups) related trace signals of methods with anomalies (e.g., exceptions, performance abnormalities such as slowness) into datasets (denominated as “cases”) based on common cause for an anomaly and correlates the signals to identify a case. The collected information may be used to differentiate between root causes of the anomalies using a comparative visualization of traces displayed on a standard user interface of the investigative platform.

Abstract: A dynamic library replacement technique enables replacement of original functions or methods of application libraries based on analysis of traces captured by a client library of an investigative platform. Traces captured from the user application are analyzed to identify the original methods of the user application that may be replaced by the client library. The original methods may be identified based on estimated performance improvements determined from the analysis of the captured traces. The improved method replacements and estimated performance improvements may be graphically presented to a user via a user interface (UI) infrastructure of the investigative platform. Replacement of the improved methods may be defined in the dynamic configuration or interactively via the UI infrastructure and continued performance monitoring reported. The specific performance for any method may be monitored along with a fidelity of the monitored method.

Abstract: An instrumentation overhead regulation technique regulates an amount of work performed by a client library of an investigative platform used to monitor, diagnose and solve errors associated with application development and production. The client library calculates processing resources utilized during its runtime activity to enable adjustment of the amount of work it performs based on the measured activity. An agent may determine the overhead activity impact to user application performance by monitoring processing resource metrics of the user application. The agent analyzes the calculated overhead and processing resource metrics to render decisions to automatically regulate the capture fidelity of the client library. Regulation of the capture fidelity may be implemented by modifying parameters of a dynamic configuration.

Abstract: An instrumentation trace capture technique enables software developers to monitor, diagnose and solve errors associated with application development and production. A client library of an investigative platform is loaded in a user application executing on a virtual machine instance of a virtualized computing environment. The client library interacts with an agent of the platform to instrument executable code of the user application and, to that end, loads a capture configuration that specifies, inter alia, methods and associated arguments, variables and data structures (values), to instrument. The client library inspects the executable code to determine portions of the code to instrument based on the capture configuration, which describes a degree of fidelity (e.g., a frequency) of the executable code and data to trace at runtime. Capture points of the runtime application are implemented as callbacks to the client library, which are registered with a runtime system executing the user application.

Abstract: An instrumentation trace capture technique enables software developers to monitor, diagnose and solve errors associated with application development and production. A client library of an investigative platform is loaded in a user application executing on a virtual machine instance of a virtualized computing environment. The client library interacts with an agent of the platform to instrument executable code of the user application and, to that end, loads a capture configuration that specifies, inter alia, methods and associated arguments, variables and data structures (values), to instrument. The client library inspects the executable code to determine portions of the code to instrument based on the capture configuration, which describes a degree of fidelity (e.g., a frequency) of the executable code and data to trace at runtime. Capture points of the runtime application are implemented as callbacks to the client library, which are registered with a runtime system executing the user application.

Abstract: A network for managing account addresses (such as for credit card accounts) where correspondence and other communications mailed to account holders may have different purposes (e.g., credit card statement, new credit card, marketing correspondence). The network has a database for storing addresses and a database management system for retrieving those addresses. A default address is provided when there is no address stored in the database for the intended purpose of a mailing. The addresses are in categories, with each category associated with a different communication purpose, and with multiple addresses in each category. The multiple addresses within each category may be permanent, temporary or repeating. If temporary or repeating, effective start and end dates are associated with the addresses. There may be multiple cardholders for each account, in which case the address categories (and multiple addresses within each category) are associated with each cardholder.

Abstract: According to another embodiment of the invention, a method of formatting communication point data comprises storing a communication point data set; storing a plurality of communication-point-formatting data sets defining how to format the communication point data set, each of the plurality of communication-point-formatting data sets defining a respective format for the content as specified by a respective format setting entity; and associating one of the communication-point-formatting data sets with the communication point data set based upon the determined application.

Abstract: According to one embodiment of the invention, a system is provided that comprises a communication point database configured to provide a communication point data set; a party database configured to provide a party data set; wherein the communication point database and the party database are communicatively coupled with one another so as to associate the communication point data set with the party data set; a relationship type code database communicatively coupled with the communication point data set and the party data set.

Abstract: A network for managing account addresses (such as for credit card accounts) where correspondence and other communications mailed to account holders may have different purposes (e.g., credit card statement, new credit card, marketing correspondence). The network has a database for storing addresses and a database management system for retrieving those addresses. A default address is provided when there is no address stored in the database for the intended purpose of a mailing. The addresses are in categories, with each category associated with a different communication purpose, and with multiple addresses in each category. The multiple addresses within each category may be permanent, temporary or repeating. If temporary or repeating, effective start and end dates are associated with the addresses. There may be multiple cardholders for each account, in which case the address categories (and multiple addresses within each category) are associated with each cardholder.

Abstract: A network for managing account addresses (such as for credit card accounts) where correspondence and other communications mailed to account holders may have different purposes (e.g., credit card statement, new credit card, marketing correspondence). The network has a database for storing addresses and a database management system for retrieving those addresses. A default address is provided when there is no address stored in the database for the intended purpose of a mailing. The addresses are in categories, with each category associated with a different communication purpose, and with multiple addresses in each category. The multiple addresses within each category may be permanent, temporary or repeating. If temporary or repeating, effective start and end dates are associated with the addresses. There may be multiple cardholders for each account, in which case the address categories (and multiple addresses within each category) are associated with each cardholder.

Abstract: According to various embodiments of the invention, an architecture is provided for a data processing system. The elements of the architecture can be managed separately. For example, the architecture can be organized around eight subject areas, such as account, party, communication point, presentation instrument, rules, balances, transactions, and product. Relationships between each of the subject areas as well as between sub-types of each subject area can be established to provide flexibility in the management of the data.

Abstract: According to various embodiments of the invention, an architecture is provided for a data processing system. The elements of the architecture can be managed separately. For example, the architecture can be organized around eight subject areas, such as account, party, communication point, presentation instrument, rules, balances, transactions, and product. Relationships between each of the subject areas as well as between sub-types of each subject area can be established to provide flexibility in the management of the data.