Common workpiece modeler

Abstract

According to some embodiments, systems and methods are provided, including: receiving a workpiece generation request; receiving a selection of a workpiece type; generating a user interface display comprising a modeling canvas, the modeling canvas comprising a client, a target, and a build space; receiving, on the modeling canvas, one or more components associated with the workpiece type, where the components are populated on the generated modeling canvas in response to the received selection of the workpiece type; receiving a stream for the workpiece type, the stream including a first link of the client to a first component of the one or more components and a second link of the target to a component of the one or more components; defining an attribute for each received component and each link; generating a workpiece; and storing the workpiece. Numerous other aspects are provided.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to Indian Provisional Patent Application No. 202311073656 filed on October 30, 2023, the contents of which are incorporated herein by reference for all purposes. Background Art

[0003] Many organizations are increasingly relying on software user interface (UI) applications that execute either internally or in the cloud, which are developed to address their needs in managing the day-to-day activities of the organization. Capabilities provided by integration platforms or other products can be used to build these applications (and systems) and integrate these applications (and systems) with each other. A central hub can be provided to access the capabilities, each of which can involve addressing its own functionality using its own different terminology, user interface, icons, etc. As a non-exhaustive example, in an integration process capability, there can be a "client" and a "target endpoint", while in an application programming interface (API) capability, the "client" is replaced by a "sender" and the "target endpoint" is replaced by a "receiver". These differences can make it challenging for users to use multiple capabilities, some of which can be used together to address specific needs.

[0004] Systems and methods that make it easier to use multiple applications within a suite of applications are desired. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] Features and advantages of example embodiments and the manner in which the same are achieved will become more apparent with reference to the following detailed description taken in conjunction with the accompanying drawings.

[0006] Figure 1 is a block diagram of an architecture according to some embodiments.

[0007] Figure 2 is a flow diagram of a process according to some embodiments.

[0008] Figure 3 is a user interface including an initial welcome page according to some embodiments.

[0009] Figure 4 According to some embodiments, in the selection Figure 3 The user interface behind the capabilities in .

[0010] Figure 5 According to some embodiments, in the selection Figure 4 The user interface following the artifact type in .

[0011] Figure 6 is a user interface after selecting a first strategy according to some embodiments.

[0012] Figure 7 According to some embodiments, Figure 6 The policy selected in the user interface.

[0013] Figure 8 is a user interface including a selection of a second policy according to some embodiments.

[0014] Fig. 9 is a mapping table according to some embodiments.

[0015] Fig.10 is a block diagram of a runtime architecture according to some embodiments.

[0016] Fig.11 is a block diagram of a cloud-based database deployment architecture according to some embodiments.

[0017] Throughout the drawings and detailed description, unless otherwise described, the same drawing reference numerals will be understood to refer to the same elements, features, and structures. The relative sizes and depictions of these elements may be exaggerated or adjusted for clarity, illustration, and / or convenience. DETAILED DESCRIPTION

[0018] In the following description, specific details are set forth in order to provide a thorough understanding of various example embodiments. It should be understood that various modifications to the embodiments will be apparent to those skilled in the art, and that the general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the present disclosure. In addition, in the following description, many details are set forth for the purpose of explanation. However, it should be understood by those of ordinary skill in the art that embodiments may be practiced without using these specific details. In other cases, well-known structures and processes are not shown or described to avoid unnecessary details that obscure the description. Therefore, the present disclosure is not intended to be limited to the embodiments shown, but to conform to the widest range consistent with the principles and features disclosed herein. It should be understood that in the development of any such actual implementation, as in any engineering or design project, many implementation-specific decisions must be made to achieve the specific goals of the developer, such as conforming to system-related and business-related constraints, which may vary from implementation to implementation. In addition, it should be understood that such development work may be complex and time-consuming, but for those of ordinary skill in the art who benefit from the present disclosure, it is still a routine task of design, manufacture and manufacture.

[0019] One or more embodiments or elements thereof may be implemented in the form of a computer program product comprising a non-transitory computer-readable storage medium having a computer-usable program code for performing the method steps indicated herein. In addition, one or more embodiments or elements thereof may be implemented in the form of a system (or device) comprising a memory and at least one processor coupled to the memory and operable to perform the exemplary method steps. In addition, on the other hand, one or more embodiments or elements thereof may be implemented in the form of a component for performing one or more method steps described herein; the component may include (i) a hardware module, (ii) a software module stored in a computer-readable storage medium (or multiple such media) and implemented on a hardware processor, or (iii) a combination of (i) and (ii); any of (i)-(iii) implements the specific techniques set forth herein.

[0020] As mentioned above, organizations can use different systems and applications to perform the daily operations of the organization. Capabilities provided by the integration platform or otherwise can be used to build and integrate different systems used by the organization. As a non-exhaustive example, application programming interface (API) management capabilities can allow users to access simple, scalable and secure digital assets through APIs. For example, using API management capabilities, users can build APIs by exposing selective data, and can handle the security and authorization required to protect, analyze and monitor their services. API management capabilities can allow users to create API designs based on open standards (including OData and OpenAPI specifications), customize and extend models, publish APIs, and protect APIs by defending against security threats, manage traffic, and cache data on edge storage (edge). Another non-exhaustive example of capabilities is cloud integration capabilities, which can allow users to build and run integration processes across cloud, on-premises and hybrid environments, where integration provides processing messages in real-time scenarios across different companies, organizations or departments within an organization. Cloud integration capabilities can provide the design and configuration of integration steps and the management of their endpoints.

[0021] Note that while API management capabilities and cloud integration capabilities are examples used herein, they are non-exhaustive and embodiments may be applicable to other suitable capabilities, including but not limited to the ability to exchange data, the ability to manage and provide integration technical guidance, the ability to evaluate migration scenarios, etc. The execution of each capability may output an artifact. As used herein, an artifact may be a tangible output of a capability and may be referred to as a "use case". Non-exhaustive examples of artifacts are API proxies, integration flows, APIs, SOAP APIs, value mappings, message mappings, data types, message types, data models, prototypes, workflow diagrams, design documents, files, source code, executable files, configuration files, etc.

[0022] With API management capabilities, a modeler can be provided whereby users can create an API proxy and manage policies for the API proxy. The API proxy sits between the client and the API, providing additional functionality to the API's access point, such as security, caching, or rate limiting, without changing the API. An API is a software interface that allows two computers or two computer programs / applications to interact with each other without any user intervention. An API is a collection of software functions / procedures (codes) that help two different software communicate with each other and exchange data. Developers and other users at an organization can build APIs to allow end users to interface with different applications and consume data from different applications. However, an organization may want to restrict access to the API because the API accesses the organization's backend servers. The API proxy can be used to restrict access to the API. The API proxy modeler can be used to configure different policies, add policies to request, response, error flows, and configure target endpoints. For example, the API proxy modeler can include a proxy endpoint pre-flow and a proxy endpoint post-flow. A process can define a processing pipeline that can control and direct how an API (or other capability) behaves and the information it carries. API proxy terms can include a request flow and a response flow. Users can apply one or more policies to a flow. Policies are steps that are executed during runtime. Policies can be created on a specific flow segment, or existing policies can be attached to a flow segment. A sequence of policies can be applied to a specific flow segment, and they can be executed in the same order in which they are applied. Non-exhaustive examples of policies are security policies (e.g., basic authentication, decode Jason Web Token (JWT), generate JWT, JavaScript Object Notation (JSON) threat protection, Extensible Markup Language (XML) threat protection, etc.), traffic management policies (e.g., access control, invalidate cache, fill cache, quota, reset quota, response cache, etc.), mediation policies (e.g., access entity, etc.). Note that each policy has its own configuration.

[0023] Conventionally, a user might first use the cloud integration capability, which includes the cloud integration modeler, to create an integration flow, model mediation steps, configure those steps, and add any authorizations and endpoints. The user might then navigate to the API management capability and use the API management modeler to create an API proxy for the designed integration, add API proxy policies, and configure them. In this scenario, two different artifacts have been created using two different modelers, each with its own lifecycle, to design an end-to-end proxy use case. It might be challenging for users to target different capabilities for one use case. It should also be noted that it might be challenging for users who have experience with one capability to then use another capability.

[0024] Embodiments solve this by providing a public modeler tool, which provides a unified canvas, property table and palette, which can be used by different capabilities to generate their respective artifacts. The palette can include one or more components. The palette can be configurable based on the type of capability, so that specific components are provided based on the type of capability. For example, in the API proxy capability, the security authorization component can be included in the palette, and in the integration capability, the content converter component can be included in the palette. Note that the authorization component may not be provided for the integration capability, and the content converter component may not be provided for the API proxy capability. The public modeler tool can provide users with, for example, modeling both the integration process and the API proxy in the same way, so that users only need to learn a process for creating artifacts (for example, reducing the learning curve of using different modelers). The public modeler tool can be configured for different capabilities. In the public modeler tool, components can be disabled or enabled according to the selected capability. The public modeler tool can also be easily extended for future artifacts generated by other capabilities. The common modeler tool may also provide reduced code maintenance because only a single modeler is maintained for updates and fixes, compared to conventional systems that use different modelers for each capability. According to some embodiments, code used with individual modelers for different capabilities may be used by the common modeler tool depending on the configuration of the capability.

[0025] In some examples, embodiments herein may be incorporated within software deployed on a cloud platform.

[0026] The environments described herein are merely exemplary, and it is contemplated that the described techniques may be extended to other implementation contexts.

[0027] Figure 1 1 is a block diagram of a system architecture 100 according to some embodiments. The illustrated elements of the system architecture 100 and all other architectures depicted herein may be implemented using any suitable combination of computing hardware and / or software that is known or becomes known. Such a combination may include one or more programmable processors (microprocessors, central processing units, microprocessor cores, execution threads), one or more non-transitory electronic storage media, and processor executable program code. In some embodiments, two or more elements of the system architecture 100 are implemented by a single computing device, and / or two or more elements of the system architecture 100 are co-located. One or more elements of the system architecture 100 may be implemented using cloud-based resources and / or other systems that elastically allocate computing resources based on demand, demand, price, and / or any other metric.

[0028] The system architecture 100 includes a backend server 102 including a common modeler tool 104 and a generation component 106, a local computing system 108 including a browser 110 running a client application 109, and a user interface 114. The system architecture 100 also includes a database 116, a database management system (DBMS) 118, and a client / user 120. As used herein, the terms "client," "user," and "end user" may be used interchangeably.

[0029] The backend server 102 may include a server application 107. The server application 107 may include server-side executable program code (e.g., compiled code, scripts, etc.) executed within the backend server 102 to receive queries / requests from the client / user 120 via the local computing system 108, and provide results to the client / user 120 based on the data of the database 116 and the output of the common modeler tool 104. The server application 107 may provide functionality (e.g., receiving a request via drag-and-drop operations, data input, and then retrieving data from the database 116 based on the request, processing the retrieved data, and providing the data to the client / user 120 via the user interface 114).

[0030] The back-end server 102 may provide any suitable interface through which the client / user 120 may communicate with the public modeler tool 104 or the application 107 / 109 executed thereon. The back-end server 102 may include a hypertext transfer protocol (HTTP) interface supporting a transient request / response protocol through a transmission control protocol / internet protocol (TCP / IP), a WebSocket interface supporting a non-instantaneous full-duplex communication of the WebSocket protocol through a single TCP / IP connection, and / or an open data protocol (OData) interface. The back-end server 102 may be separated or tightly integrated with the DBMS 118. A tightly integrated back-end server 102 may enable the execution of the application 107 completely on the database platform without the need for an additional server. For example, the back-end server 102 may provide a comprehensive set of embedded services that provide end-to-end support for Web-based applications. The back-end server 102 may provide application services (e.g., via a function library) that the application 107 may use to manage and query database files stored in the database 116. Application services may be used to expose the database data model and its tables, hierarchies, views, and database procedures to clients / users 120. In addition to exposing the data model, the backend server 102 may also host system services, such as search services, and the like.

[0031] The local computing system 108 may include a computing system operated by a local user 120. The local computing system 108 may include a laptop computer, a desktop computer, or a tablet computer, but the embodiments are not limited thereto. The local computing system 108 may be composed of any combination of computing hardware and software suitable for allowing the local computing system 108 to execute program code to cause the local computing system 108 to perform the functions described herein and to store such program code and associated data.

[0032] Typically, the local computing system 108 executes one or more applications 109 to provide functionality to the client / user 120. The application 109 may include any software application that is known or becomes known, including but not limited to integrated applications. As will be described below, the application 109 may include a web application that is executed within a web browser 110 of the local computing system 108 and interacts with a corresponding server application 107 to provide the desired functionality. The client application 109 may send a user interface request (or other suitable request) to a server-side or back-end application ("server application") 107 for execution. For example, when a user clicks a button or enters information via the UI of the client application 109, a request is sent to the back-end server 102. The back-end server then responds with content that needs to be presented / then provided to the client application. The user 120 may interact with a user interface 114 displayed as a result of the execution output of the application to design and create artifacts and then deploy those artifacts.

[0033] The client / user 120 can access the common modeler tool 104 executed with the backend server 102 to generate one or more artifacts 122. The common modeler tool 104 can provide the design and creation of an artifact model 125 for each of the plurality of capabilities 126. After the artifact model 125 is created using the common modeler tool 104, the artifact 122 is constructed based on the artifact model 125 by the generation component 106.

[0034] The common modeler tool 104 can access data in the database 116 and retrieve the data so that it is provided at runtime. Although discussed further below, the database 116 can store data representing artifacts 122, configuration data 124 for each capability, and other suitable data. The selection of capabilities and artifact types for generation can cause the common modeler tool 104 to retrieve the configuration data 124 from the database 116 and present components representing the configuration data 124 on a user interface for the selected artifact type, as described further below. The database 116 represents any suitable combination of volatile (e.g., random access memory) and non-volatile (e.g., fixed disk) storage used by the system to store data.

[0035] One or more applications 107 / 109 executing on the backend server 102 or local computing system 108 can use a database management interface (such as, but not limited to, Open Database Connectivity (ODBC) and Java Database Connectivity (JDBC) interfaces) to communicate with the DBMS 118. These types of applications 107 / 109 can use structured query language (SQL) to manage and query data stored in the database 116.

[0036] DBMS 118 services requests to store, retrieve, and / or modify data in database 116, and also performs administrative and management functions. Such functions may include snapshot and backup management, indexing, optimization, garbage collection, and / or any other database functions that are or become known. According to some embodiments, DBMS 118 may also provide application logic, such as database procedures and / or calculations. The application logic may include scripts, function libraries, and / or compiler code. DBMS 118 may include any query-responsive database system that is or becomes known, including but not limited to a structured query language (i.e., SQL) relational database management system.

[0037] The database 116 may store data used by at least one of the applications 107 / 109 and the common modeler tool 104. For example, the database 116 may store configuration data mapped to specific artifacts, which may be accessed by the common modeler tool 104 during its execution.

[0038] Database 116 may include any query responsive data source that is known or becomes known, including but not limited to a structured query language (SQL) relational database management system. Database 116 may include a relational database, a multidimensional database, an extensible markup language (XML) document, or any other data storage system that stores structured and / or unstructured data. The data of database 116 may be distributed among several relational databases, dimensional databases, and / or other data sources. Embodiments are not limited to any number or type of data sources.

[0039] Presentation of a user interface as described herein may include any degree or type of rendering, depending on the type of user interface code generated by the backend server 102 / local computing system 108 .

[0040] For example, client / user 120 may execute browser 110 to request and receive web pages (e.g., in HTML format) from server application 107 of backend server 102 to provide user interface 114 via HTTP, HTTPS, and / or WebSocket, and may render and present the web pages according to known protocols.

[0041] Figure 2200 for generating an artifact according to an example embodiment. According to some embodiments, process 200 may be performed by a database node, a cloud platform, a server, a computing system (user device), a combination of devices / nodes, etc. In one or more embodiments, system architecture 100 may be adjusted to perform process 200 so that processing unit 1135 ( Fig.11 ) is a special-purpose component configured to perform operations that cannot be performed by a general-purpose computer or device.

[0042] All processes mentioned herein may be performed by various hardware elements and / or embodied in processor executable program code read from one or more of a non-transitory computer readable medium such as a hard drive, floppy disk, CD-ROM, DVD-ROM, flash drive, flash memory, magnetic tape, and solid-state random access memory (RAM) or read-only memory (ROM) storage unit and then stored in a compressed, uncompiled, and / or encrypted format. In some embodiments, hardwired circuitry may be used in place of or in combination with program code for implementation in the process according to some embodiments. Therefore, embodiments are not limited to any particular combination of hardware and software.

[0043] Prior to process 200, configuration data 124 may be mapped to each capability 126 and artifact type 902, such as Fig. 9 . As shown in the mapping 900. As described above, non-exhaustive examples of capabilities 126 are API management capabilities, integration process capabilities, and data exchange capabilities. As further described above, for each capability 126, there may be one or more artifact types 902 that can be output by executing the capability. As non-exhaustive examples, for API management capabilities 126, artifact type 902 may be API, API proxy, etc.; for integration process capabilities 126, artifact type 902 may be integration process; and for data exchange capabilities, artifact type 902 may be a data transfer model. Configuration data 124 may include multiple selectable components 904. Components 904 may include attributes 906 that may further define artifact type 902. Optional components 904 may be displayed on the artifact generation user interface display 500, as described below with respect to Figure 5-8As further described. As a non-exhaustive example, for an API proxy, there may be a category item "security policy", which may include multiple components 904. As a non-exhaustive example, the "security policy" category item may have the following components 904: "authentication", "authorization", and "JSON threat protection". Each of these components 904 may have configurable properties 906. For the "authorization" component 904, the properties 906 may include the policy setting scope and type (e.g., client authentication and / or OAuth (open authorization)). For an API proxy, another category item may be "traffic management policy", and one of the multiple components 904 for this category may be "quota". The properties 906 of the "quota" component 904 may include, but are not limited to, error instructions, mode, start time, number of calls, duration, duration unit, and quota identifier. As another non-exhaustive example, for an integration process, a category item may be "transformation", which may include components 904 of "converter", "decoder", "encoder", "extractor", "filter", and "content modifier". For a "content modifier" component 904, one of the properties 906 may be a condition for modifying the content (e.g., if the request includes X, replace X with y). For an integration flow, another category item may be a "process," which may include components 904 of an "exception subprocess," an "integration process," and a "local integration process." As described above, the mapping 900 may be stored in the database 116 and accessed by the generic modeler tool 104 during its execution.

[0044] Go to Figure 2 Initially, at S210, a common modeler tool dashboard user interface (UI) 300 ( Figure 3 ). The common modeler tool dashboard UI 300 may include a plurality of capability icons 302. As described above, each capability icon 302 may represent a capability 126. As a non-exhaustive example to be used below, the "Manage API" capability icon 302 is selected. In response to the selection of the capability icon 302, the capability user interface display 400 ( Figure 4 ). Capability UI display 400 may include one or more selectable artifact icons 402 representing artifact types 902. In S214, selection of artifact icon 402 may send an artifact generation request. Note that in some embodiments, the capability itself may represent an artifact type. In this case, processing may proceed directly from S210 to S214 without proceeding to S212, whereby selection of capability icon 302 may send an artifact generation request in S214. Based on the selected artifact type (or capability) included in the request, common modeler tool 104 may access mapping 900 to retrieve configuration data 124 for the selected artifact type in S216.

[0045] In S218, the workpiece generation user interface display 500 ( Figure 5 ). The artifact generation user interface display 500 can be populated based on the retrieved configuration data 124. As described above, the configuration data 124 can include multiple selectable components 904. The components 904 can include attributes 906 that further define the artifact type 902. According to some embodiments, each component can include one or more sub-components. As a non-exhaustive example, for an API proxy artifact and an authentication policy component, each policy step (e.g., receiving a token as part of a request, retrieving stored token information from a receiver, comparing the received token to the stored token information, and determining whether the authentication is valid or invalid based on the comparison) can be a sub-component.

[0046] Artifact generation user interface display 500 may include one or more selectable menu tabs 501. Selection of menu tab 501 may allow a user to view and / or configure a component. Here, the menu tabs are "Overview", "Target Endpoint", "Resources", and "Strategy". Figure 5 As shown, the “Policy” menu tab 501 is selected, as indicated by the shading of the menu tab 501 .

[0047] The artifact generation user interface display 500 may also include a configurable modeling palette 502, which includes a plurality of selectable palette item icons 504. The artifact generation user interface display 500 may also include a modeling canvas 506. The selectable palette item icons 504 may represent the above-mentioned category items. Each selectable palette item icon 504 may include one or more selectable components 508. Note that in some instances, the selectable palette item icons 504 may be selectable components 508 themselves. The selectable components 508 may be provided via a drop-down menu 510 or any other suitable display. The palette item icons 504 and the associated selectable components 508 are populated on the artifact generation user interface display 500 based on the retrieved configuration data 124. According to some embodiments, the palette item icons 504 may be populated on the modeling canvas in response to the selection of an artifact type, and the particular palette item icon 504 that is populated is based on the selected artifact type. The modeling canvas 506 may provide a visualization of a model, a process, etc. The artifact model 125 may be designed by including a client, a target, one or more components, and one or more flows on a modeling canvas, as further described below. The modeling canvas 506 may initially be populated with a client 512, a target 514, and a build space 516. In S220, one or more components 508 associated with an artifact type are received on the modeling canvas 506. The components 508 may be received via a drag-and-drop action or any other suitable process.

[0048] As a non-exhaustive example shown herein, the "Security Policy" palette item icon 504 is selected, as indicated by the shading. Selecting the "Security Policy" palette item icon 504 can cause a drop-down menu 510 to include components 508: "Authentication", "Authorization", and "JSON Threat Protection". Here, the "Authentication" component 508 is selected, as indicated by the shading. As described above, the user can select the "Authentication component" 508 and drag and drop it onto the modeling canvas 506 (in this case, the construction space 516), as indicated by the curved dashed arrow 518. Here, the "Authentication" component 508 is the first component of the artifact model 125.

[0049] In S222, the process 602 ( Figure 6 ). Process 602 may include links 604 between client 512, one or more components 508 in build space 516, and target 514 to connect (link) elements of artifact model 125. Note that in some instances, link 604 may be received between client 512 and build space 516 and / or between build space 516 and target 514 before any components are received in build space 516. Figure 6 As shown, link 604 can be represented by a dotted arrow or a solid arrow. Here, client 512 is linked to first message component 508, which is in turn linked to authentication component 508, which is in turn linked to request reply component 508. Request reply component 508 is linked to both target 514 and second message component 508. Second message component 508 is linked to client 512. Note that process 602 can include component 508 within build space 516, which is not linked to other components / clients / targets, but is still part of process 602. Here, "abnormal subprocess 1" component 508 is part of process 602, but is not directly linked to other components / clients / targets via link 604. In this process 602, client 512 sends a message (message component) received by the authentication component. After successful authentication, the authentication component sends a request reply to target 514 via request reply component 508. Target 514 generates a response and returns the response to reply request component 508. The reply request component 508 sends a response message (second message component) back to the client 512. In the event that authentication is unsuccessful, for example, the exception sub-process 1 component can be executed based on configurable properties, as described further below.

[0050] Transitioning to S224, one or more attributes 906 may be defined for each received component and each received link. Non-exhaustive examples of the attributes 906 that may be defined for each link may be a type of communication protocol between at least one of: (i) a client and a component, (ii) a target and a component, and (iii) a first component and a second component. The communication protocol may include, but is not limited to, HTTP, HTTPS, JSON, XML, etc. Selection of a component 508 (or link 604) may result in display of an attribute table 702, such as Figure 7 shown.

[0051] Attribute table 702 ( Figure 7 ) may be a pop-up window or otherwise displayed in response to selection of a component 508 on the modeling canvas 506. Here, the "Authentication" component 508 is selected, as indicated by the shading, resulting in the display of a property sheet 702. The configuration properties displayed on the property sheet 702 are based on the configuration data 124 from the mapping 900. The property sheet 702 may include one or more categories 704 of properties for configuration. Here, there is a "General" category 704 and a "Policy Settings" category 704. Selecting the "Policy Settings" category 704, as indicated by the shading, results in the display of one or more policy setting properties (e.g., type, etc.) for configuration. In this case, the policy setting property type is defined as: Client Certificate and Oauth. Other suitable types of policy setting properties may be provided.

[0052] Note that while the above process describes receiving a stream (S222) before defining properties (S224), these steps may be reversed, and properties of each component may be defined before receiving the stream 602, or properties of one or more components may be defined, then the stream is received, and other properties may then be defined, etc. For example, after the construction space 516 receives the component 508, the defined properties 906 for the component 508 may be received before the modeling canvas 506 receives any additional components or links. Similarly, in some cases, the properties of each link may be defined before receiving the stream 602. For example, the link 604 may be received between the client 512 and the construction space 516 and / or the construction space 516 and the target 514 before the component is received in the construction space 516. At this stage, properties 906 may be defined for the link.

[0053] Continuing with the above example, after defining the properties of the "authentication" component 508 in S224, another component may be received by the modeling canvas 506, such as Figure 8Here, the "Traffic Management" palette item icon 504 is selected, as indicated by shading. Selection of the "Traffic Management" palette item icon 504 may result in a drop-down menu 510 including the following components 508: "IP Filters," "Quotas," and "Surge Protection." Here, the "Quota" component 508 is selected as indicated by shading and dragged and dropped onto the modeling canvas as indicated by the curved dashed arrow 518.

[0054] Returning to process 200, after one or more components, flows, and property definitions have been added to modeling canvas 506, the artifact model can be complete. In response to selection of "Generate" icon 550, artifacts 122 can be generated for artifact model 125 in S226 via generation component 106. In S228, artifacts 122 can be stored in database 116.

[0055] Fig.10 A block diagram of a runtime architecture 1000 for deployment of artifacts according to an example embodiment is provided. Fig.10 The runtime architecture 1000 shown in is for an API proxy, but continuing the above example, the runtime architecture can be applied to other artifacts. The runtime architecture 1000 may include a load balancer 1002, an authentication server 1004, an integration runtime 1006, and a backend server 102. The load balancer 1002 can effectively distribute incoming network traffic across a group of backend servers. The integration runtime 1006 can provide a computing environment that directly runs or dispatches activities. Here, the integration runtime 1006 may include an API policy engine 1008 and a cloud platform integration node 1010. During runtime, the load balancer 1002 may receive a uniform resource locator (URL) request 1012 and identify the backend server 102 to receive the URL request 1012. The load balancer 1002 may forward the URL request 1012 to the API policy engine 1008 to execute the policy for the security policy defined above. Keeping with the above example, the API proxy includes an authentication component that is defined so that the API policy engine 1008 can exchange the Jason Web Token (JWT) for security materials of the authentication server 1004. If the authentication server 1004 determines that the exchanged materials are valid, the API policy engine 1008 can forward the JWT to the cloud platform integration node 1010. The cloud platform integration node 1010 can then execute the integration steps of the integration process (not shown). The integration process can be another artifact generated by the above process 200. The execution of the integration steps can include access to the backend server 102.

[0056] Fig.11A cloud-based database deployment 1100 is shown according to some embodiments. The illustrated components may reside in one or more public clouds that provide self-service and immediate provisioning, automatic scaling, security, compliance, and identity management features.

[0057] The user device 1110 may interact with an application executed on one of the cloud application server 1120 or the on-premises application server 1125, for example, via a web browser executed on the user device 1110, to create, read, update, and delete data managed by the database system 1130. The database system 1130 may store data as described herein, and may perform processes as described herein so that the public modeler tool 104 is executed for use with the user device 1110. The cloud application server 1120 and the database system 1130 may include cloud-based computing resources, such as virtual machines, allocated by a public cloud provider. In this way, the cloud application server 1120 and the database system 1130 may be subject to demand-based resource elasticity. Each of the user device 1110, the cloud application server 1120, the on-premises application server 1125, and the database system 1130 may include a processing unit 1135, which may include one or more processing devices, each of which includes one or more processing cores. In some examples, the processing unit 1135 is a multi-core processor or multiple multi-core processors. In addition, the processing unit 1135 may be fixed, or it may be reconfigurable. The processing unit 1135 may control the components of any one of the user device 1110, the cloud application server 1120, the on-premises application server 1125, and the database system 1130. The storage device 1140 may not be limited to a specific storage device, and may include any known memory device, such as RAM, ROM, hard disk, etc., and may or may not be included in the database system, cloud environment, web server, etc. The storage device 1140 may store data that can be executed by the processing unit 1135 to perform Figure 2 The software modules or other instructions / executable codes of the processes shown in . According to various embodiments, the storage device 1140 may include a data storage having multiple tables, records, partitions and sub-partitions. The storage device 1140 may be used to store database records, documents, entries, etc.

[0058] As will be understood based on the foregoing description, the above examples of the present disclosure may be implemented using computer programming or engineering techniques including computer software, firmware, hardware, or any combination or subset thereof. Any such obtained program with computer readable code may be embodied or provided in one or more non-transitory computer readable media, thereby manufacturing a computer program product, i.e., a product, according to the examples discussed in the present disclosure. For example, a non-transitory computer readable medium may be, but is not limited to, a fixed drive, a disk, an optical disk, a tape, a flash memory, an external drive, a semiconductor memory (such as a read-only memory (ROM), a random access memory (RAM)), and / or any other non-transitory sending and / or receiving medium (such as the Internet, cloud storage, the Internet of Things (IoT) or other communication networks or links). Products containing computer code may be manufactured and / or used by executing the code directly from one medium, by copying the code from one medium to another, or by transmitting the code over a network.

[0059] A computer program (also referred to as a program, software, software application, "app" or code) may include machine instructions for a programmable processor and may be implemented in high-level procedural and / or object-oriented programming languages ​​and / or assembly / machine languages. As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, apparatus, cloud storage, Internet of Things, and / or device (e.g., disk, optical disk, memory, programmable logic device (PLD)) for providing machine instructions and / or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. However, "machine-readable medium" and "computer-readable medium" do not include transient signals. The term "machine-readable signal" refers to any signal that can be used to provide machine instructions and / or any other kind of data to a programmable processor.

[0060] The above description and illustration of the process herein should not be considered to imply a fixed order for performing the process steps. Instead, the processing steps can be performed in any feasible order, including performing at least some steps simultaneously. Although the present disclosure has been described in conjunction with specific examples, it should be understood that various changes, substitutions and modifications that are obvious to those skilled in the art may be made to the disclosed embodiments without departing from the spirit and scope of the present disclosure set forth in the appended claims.

Claims

1. A system comprising: A memory storing a processor executable program code; as well as a processing unit, configured to execute the processor executable program code so that the system: receiving an artifact generation request; receiving a selection of an artifact type; generating a user interface display including a modeling canvas, the modeling canvas including a client, a target, and a build space; receiving one or more components associated with the artifact type on the modeling canvas; receiving a flow for the artifact type, the flow comprising a first link from the client to a first component of the one or more components and a second link from the target to one of the one or more components; Define properties for each received component and each link; Generate artifacts; as well as The artifact is stored.

2. The system according to claim 1, wherein: The artifact is an application programming interface (API) proxy.

3. The system according to claim 2, wherein: The first component is an authentication policy component.

4. The system of claim 1 , further comprising a processor executable program code to cause the system to: Receives one or more subcomponents for each component.

5. The system according to claim 4, wherein: The artifact is an API proxy, the first component is an authentication policy component, and each subcomponent is a policy step.

6. A system according to claim 1, wherein the attributes defined for the link define a type of communication protocol between at least one of: (i) the client and the first component, (ii) the target and the first component, and (iii) the first component and a second component.

7. The system of claim 1, further comprising processor-executable program code for causing the system to deploy the artifact.

8. The system of claim 1, wherein each component is represented on the modeling canvas by a palette item icon.

9. The system according to claim 8, wherein: In response to selection of the artifact type, the palette item icons are populated on the modeling canvas.

10. The system according to claim 9, wherein: The palette item icons are based on the selected artifact type.

11. A method comprising: receiving an artifact generation request; receiving a selection of an artifact type; generating a user interface display including a modeling canvas, the modeling canvas including a client, a target, and a build space; receiving one or more components associated with the artifact type on the modeling canvas, wherein the components are populated on the generated modeling canvas in response to a received selection of the artifact type; receiving a flow for the artifact type, the flow comprising a first link from the client to a first component of the one or more components and a second link from the target to one of the one or more components; Define properties for each received component and each link; Generate artifacts; and The artifact is stored.

12. The method according to claim 11, wherein: The artifact is an application programming interface (API) proxy.

13. The method according to claim 12, wherein: The first component is an authentication policy component.

14. The method according to claim 11, wherein: The attributes defined for the link define a type of communication protocol between at least one of: (i) the client and the first component, (ii) the target and the first component, and (iii) the first component and a second component.

15. The method according to claim 11, further comprising: Deploy the artifact.

16. The method according to claim 11, wherein: Each component is represented by a palette item icon on the modeling canvas.

17. The method according to claim 16, wherein: The palette item icons are based on the selected artifact type.

18. A non-transitory computer readable medium having stored therein executable instructions for performing a method, the method comprising: receiving an artifact generation request; receiving a selection of an artifact type; generating a user interface display including a modeling canvas, the modeling canvas including a client, a target, and a build space; receiving one or more components associated with the artifact type on the modeling canvas, wherein the components are populated on the generated modeling canvas in response to a received selection of the artifact type; receiving a flow for the artifact type, the flow comprising a first link from the client to a first component of the one or more components and a second link from the target to one of the one or more components; Define properties for each received component and each link; Generate artifacts; and The artifact is stored.

19. The medium according to claim 18, wherein The artifact is an application programming interface (API) proxy.

20. The medium of claim 18, further comprising: Deploy the artifact.

Images