Dynamic Workflow Input via API Schema Introspection

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing workflow management systems face challenges in integrating with remote services that have unknown or changing schemas, leading to inefficiencies and failures when accessing and manipulating data.

Innovation Solution

The development of graphical user interfaces and mechanisms that allow for dynamic input during workflow design, enabling adaptation to schema changes by introspecting the remote service's current schema, thus allowing actions and workflows to be defined without hard-coding specific schema versions.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If the remote network management platform is configured with a fixed schema to access remote services, then the platform can reliably access and manipulate data, but the platform fails or cannot access all information when the remote service schema changes

Engineering Contradiction:
Improveworkflow execution reliabilityVSAvoidschema change adaptability
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The patent implements dynamic input parameters in workflow actions that can adapt to schema changes. Instead of hard-coding fixed schema versions, the system dynamically determines input parameters based on the current remote service schema, allowing workflows to automatically adjust when schemas change without manual intervention or failure

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The system changes the parameters of workflow actions from fixed, pre-defined values to dynamic values that are determined at runtime based on the actual remote service schema. This allows the same workflow template to work with different schema versions by automatically adjusting input parameters to match the current service definition

Inventive Principle:
Principle #35Parameter changes

2Stability of the object's composition

If the platform hard-codes specific schema versions in workflow definitions, then the workflow definition is simple and stable, but the workflow cannot adapt to schema changes and requires code updates

Engineering Contradiction:
Improveworkflow definition stabilityVSAvoidschema version adaptability
Core Design Contradiction:
Stability of the object's compositionVSAdaptability or versatility

Solution Approach 1:

The patent introduces dynamic input parameters that are resolved at workflow execution time rather than definition time. The workflow definition remains stable and version-agnostic, while the actual parameter values are dynamically determined by introspecting the current remote service schema, separating the stable workflow logic from the changing schema details

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The system enables workflows to self-adapt to schema changes by automatically introspecting the remote service schema and adjusting input parameters without requiring manual code updates. The workflow engine itself performs the adaptation by dynamically determining the correct parameter values based on the current service definition

Inventive Principle:
Principle #25Self-service

3Adaptability or versatility

If the platform manually updates workflow definitions to support schema changes, then the platform can maintain compatibility, but the time and complexity of supporting APIs increases

Engineering Contradiction:
Improveschema compatibilityVSAvoidworkflow update time
Core Design Contradiction:
Adaptability or versatilityVSLoss of time

Solution Approach 1:

The patent implements automatic schema introspection and adaptation, where the workflow engine automatically detects schema changes and adjusts input parameters without requiring manual intervention. This self-service mechanism eliminates the time-consuming process of manually updating workflow definitions whenever the remote service schema changes

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The system incorporates feedback loops where the workflow engine continuously introspects the remote service schema and uses this information to automatically adjust workflow parameters. This feedback mechanism ensures compatibility is maintained automatically by detecting schema changes and adapting the workflow definition accordingly

Inventive Principle:
Principle #23Feedback

4Adaptability or versatility

If the platform uses dynamic input parameters to adapt to schema changes, then the platform gains flexibility and no-code workflow definition, but the system complexity increases

Engineering Contradiction:
Improveworkflow flexibilityVSAvoidsystem architecture complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent introduces an intermediary layer between the workflow definition and the remote service execution. This intermediary dynamically determines input parameters by introspecting the service schema and mapping them to workflow variables, absorbing the complexity of schema adaptation while keeping the workflow definition simple and user-friendly

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentEP3942491B1Workflow support for dynamic action input
Publication Date: 2024.01.17 SERVICENOW INC
  • EP3942491B1 patent drawingFigure 1
  • EP3942491B1 patent drawingFigure 2
  • EP3942491B1 patent drawingFigure 3

AI summary

Persistent storage may contain a definition of an application programming interface (API) of a remote service, where the API provides access to input information stored at the remote service. One or more processors may be configured to: (i) provide, for display on an action design graphical user interface (GUI), a first menu that allows selection of a first set of the input information to be dynamically retrieved from the API during design of a workflow; (ii) provide, for display on the action design GUI, a second menu that allows selection of a second set of the input information to be dynamically retrieved from the API during design of the workflow; and (iii) provide for display, on the action design GUI, options for specifying the API, how to remotely access the API, and how to parse data received from the API.