KR20250122799A - Appartus for providing application services, method thereof, and computationally-implementable storage medium for storing a program for providing application services - Google Patents

Abstract

One embodiment of the disclosure provides a method for providing an application service, comprising: a computing system managing a platform that provides clients with isolated workspaces in which application packages are executed; obtaining a source schema for EDI document data; mapping the source schema to a target schema for target document data using a graphical tool; and converting the EDI document data to target document data based on the mapping.

Description

{APPARTUS FOR PROVIDING APPLICATION SERVICES, METHOD THEREOF, AND COMPUTATIONALLY-IMPLEMENTABLE STORAGE MEDIUM FOR STORING A PROGRAM FOR PROVIDING APPLICATION SERVICES}

The following disclosure relates to an application service providing device, an application service providing method, and a storage medium storing a computer-executable program providing an application service.

In transactions between companies or between companies and individuals, information related to the transaction or documents containing that information are exchanged.

However, the exchange of documents, the format or specifications of the information to be included in the documents, may vary from company to company, and the format of the documents, the contents of the internal requests, or the method of description may differ depending on the type of transaction, so various software programs have been developed.

Such software can help businesses enter and exchange information necessary for transactions in standardized formats, such as electronic document exchange (EDO). As this EDO becomes more widespread, standardized methods will be established, converting these documents into standardized electronic documents and exchanging, storing, and processing them on the computers of the parties involved in the transaction will save time and effort.

However, the software that generates these standardized electronic documents often has the inconvenience of having to be individually changed depending on the parties to the transaction, the nature of the transaction, and the format and content of the transaction.

For newcomers to the market, it can be difficult to prepare standardized forms and formats required by existing transaction parties. The market's complex transaction patterns and requirements often make it difficult to understand or follow these standardized transaction formats, making it difficult to facilitate transactions.

Additionally, when the parties to a transaction use incompatible software or have separate software for incompatible systems, there are technical inconveniences such as having to develop software for the transaction or having software tailored to the system.

Even if application services are provided with the same software image, there are difficulties in providing efficient services, such as having to prepare and provide software packages of all versions and types for each client.

In particular, there is a need for the entire system to continue to operate without interruption even if problems occur with the servers or computing resources used by the transaction parties, and for the system to be able to flexibly respond to increases in the number of users or the amount of data.

The disclosed embodiment is intended to solve the above-mentioned inconvenient problems, and may provide an application service providing device, an application service providing method, and a storage medium for storing a program executable by a computer that provides an application service to support non-stop scale-out through distributed package replication and distributed channel communication.

One embodiment of the disclosure provides a method for providing an application service, comprising: a computing system managing a platform that provides clients with isolated workspaces in which application packages are executed; obtaining a source schema for EDI document data; mapping the source schema to a target schema for target document data using a graphical tool; and converting the EDI document data to target document data based on the mapping.

The source schema includes metadata representing at least one of an EDI transaction, segment, and data element for the EDI document data.

The mapping step includes: setting a target schema for the target document data; determining at least one of a resource path, a resource file, and an EDI transaction for the source schema and the target schema; and mapping at least one of a hierarchically structured segment and data element of the source schema to the target schema based on at least one of the resource path, the resource file, and the EDI transaction.

The above converting step includes: a step of parsing data elements from the EDI document data; and a step of converting the parsed data elements into a data format and data structure of the target document data based on a mapping between the source schema and the target schema.

The above application service providing method further includes, after the converting step, a step of transmitting the converted target document data to a partner.

One embodiment of the disclosure provides an application service providing device, comprising: a database for storing data; and a processor for processing the data, wherein the processor is configured to obtain a source schema for EDI document data, map the source schema to a target schema for target document data using a graphical tool, and convert the EDI document data to target document data based on the mapping, in a computing system managing a platform that provides a client with an isolated workspace in which an application package is executed.

The source schema includes metadata representing at least one of an EDI transaction, segment, and data element for the EDI document data.

The processor sets a target schema for the target document data, determines at least one of a resource path, a resource file, and an EDI transaction for the source schema and the target schema, and maps at least one of a hierarchically organized segment and data element of the source schema to the target schema based on at least one of the resource path, the resource file, and the EDI transaction.

The processor parses data elements from the EDI document data, and converts the parsed data elements into a data format and data structure of the target document data based on a mapping between the source schema and the target schema.

The above processor transmits the converted target document data to the partner.

One embodiment of the disclosure provides a computer-executable program for providing an application service that performs the steps of obtaining a source schema for EDI document data, mapping the source schema to a target schema for target document data using a graphical tool, and converting the EDI document data to target document data based on the mapping, in a computing system managing a platform that provides clients with isolated workspaces in which application packages are executed, and storing a storage medium.

According to the disclosed embodiment, technical inconveniences for transactions can be resolved and transactions can be made more active.

According to the disclosed embodiment, it is possible to technically activate market transactions using software even when a standardized form for existing transactions is not available or there are complex transaction requirements.

According to the disclosed embodiment, a convenient transaction system can be provided even when the transaction parties use incompatible software or have separate software in incompatible systems.

According to the disclosed embodiment, there is an advantage in that a mapping program can be defined relatively easily even if the user is not familiar with development scripts.

According to the disclosed embodiments, developers can easily implement and manage complex mapping logic through a user-friendly interface and visual programming approach.

According to the disclosed embodiment, by distributing a software package across multiple worker nodes (physical servers), actual services can be performed without interruption even if a failure occurs in one worker node.

Figure 1 is a flowchart disclosing an example of a method for providing an application service according to an embodiment.
FIG. 2 is a drawing showing an example of providing application services to a client through a workspace among the disclosed embodiments.
Figure 3 is a conceptual diagram disclosing layer-by-layer elements for providing application services according to an embodiment.
FIG. 4 is a drawing disclosing a specific example of an application service providing device according to an embodiment establishing a channel between an instance and a client or partner.
FIG. 5 is a diagram showing an example of setting up a distributed channel and providing a service according to an embodiment.
FIG. 6 is a drawing disclosing an example of managing setting information of a package installed according to an embodiment.
Figure 7 is a drawing showing an example of managing and using a package according to a workspace of an embodiment of the disclosure.
FIG. 8 is a diagram disclosing an example of mapping EDI information as a type of application service according to an embodiment.
FIG. 9 is a drawing disclosing an example of providing an application service using an integrated package according to an embodiment.
FIG. 10 is a drawing showing an example of an interface of a platform according to an example of providing an application service disclosed.
FIG. 11 is a drawing showing another example of the interface of a platform according to an example of providing an application service disclosed.
FIG. 12 is a drawing disclosing an example of a framework that allows an application service providing device according to an embodiment to integrate different systems.
Figure 13 is a drawing showing an example of graphically coding connectors and services among integration flow functions when developing an integration flow based on an embodiment.
Figure 14 is a drawing showing an example of graphically coding the processor, control flow, and modifier among the integration flow functions when developing an integration flow based on an embodiment.
FIG. 15 is a drawing illustrating an interface of an agent when an agent provided on a platform of an instance system according to an embodiment is executed.
FIG. 16 is a drawing illustrating an example of an interface of an agent adapter provided on a platform of an instance system according to an embodiment.
FIG. 17 is a drawing illustrating another example of an interface of an agent adapter provided on a platform of an instance system according to an embodiment.
Figure 18 is a diagram showing an example of an agent adapter of a platform of an instance system according to an embodiment setting up a transmission and reception channel.
FIG. 19 is a drawing showing an example of transmitting EDI data, which is transaction information, using a platform of an instance system according to an embodiment.
FIG. 20 is a drawing disclosing an embodiment of running an adapter in a workspace according to an embodiment.
Figure 21 is a drawing disclosing an example of an adapter package.
Figure 22 is a drawing disclosing an example of an adapter using a framework according to an embodiment.
Figure 23 is a drawing disclosing an example of a service provided by an adapter package according to an embodiment.
Figure 24 is a drawing disclosing an example of an adapter developed in a workspace according to an embodiment.
FIG. 25 is a drawing disclosing an example of an application service providing device converting a data format according to an embodiment.
FIG. 26 is a diagram showing an example of an application service providing device converting a data format using a schema and a mapping script according to an embodiment.
Figure 27 is a diagram disclosing an example of deserialization and serialization based on a schema according to an embodiment.
Figure 28 is a drawing disclosing an example of a mapping script according to an embodiment.
FIG. 29 is a drawing showing an example of providing a user interface for developing a mapping flow among the disclosed embodiments.
FIG. 30 is a drawing showing an example of providing a user interface for developing a mapping flow among the disclosed embodiments.
FIG. 31 is a drawing showing an example of providing a user interface for developing a mapping flow among the disclosed embodiments.
FIG. 32 is a drawing showing an example of providing a user interface for developing a mapping flow among the disclosed embodiments.
FIG. 33 is a drawing showing an example of providing a user interface for developing a mapping flow among the disclosed embodiments.
FIG. 34 is a drawing showing an example of providing a user interface for developing a mapping flow among the disclosed embodiments.
FIG. 35 is a drawing disclosing an example of an application service providing device according to an embodiment creating and testing an integrated package.
FIG. 36 is a drawing disclosing an example of providing a user interface for developing an integrated flow according to an embodiment.
FIG. 37 is a drawing disclosing an example of providing a user interface for developing an integrated flow that performs mapping according to an embodiment.
Figure 38 is a drawing disclosing an example of providing a web EDI service using a message box according to an embodiment.
Figure 39 is a drawing disclosing an example of providing a web EDI service using a message box according to an embodiment.
FIG. 40 is a drawing showing an example of an interface of a platform according to an embodiment.
Figure 41 is a drawing showing an example of a user interface of a web EDI service according to an embodiment.
FIG. 42 is a diagram illustrating an example of a user interface of an inbox document service according to an embodiment.
FIG. 43 is a diagram illustrating another example of a user interface of an inbox document service according to an embodiment.
FIG. 44 is a diagram illustrating an example of a user interface of a draft document service according to an embodiment.
FIG. 45 is a diagram illustrating an example of a user interface of a draft document service according to an embodiment.
FIG. 46 is a diagram illustrating an example of a user interface of a draft document according to an embodiment.
FIG. 47 is a diagram illustrating an example of a user interface of a cent document according to an embodiment.
Figure 48 is a flowchart illustrating an application service provision method for providing a web EDI service according to an embodiment.
Figure 49 is a drawing showing the operation of a scrap adapter according to an embodiment.
Figure 50 is a drawing showing an example of a user using a scrap adapter according to an embodiment.
FIG. 51 is a drawing illustrating an example of a user interface of a platform according to an embodiment.
FIG. 52 is a drawing illustrating an example of a user interface of a platform according to an embodiment.
Figure 53 is a drawing disclosing a data collection method according to another embodiment.
Figure 54 is a drawing showing the operation of a scrap adapter according to an embodiment.
FIG. 55 is a diagram showing an example of an application service providing device according to an embodiment converting data based on a source schema for EDI document data.
Figure 56 is a diagram disclosing an example of a source schema for EDI document data according to an embodiment.
FIG. 57 is a drawing disclosing an example of a user interface for setting a target schema for target document data according to an embodiment.
FIG. 58 is a drawing disclosing an example of a user interface for setting up a source schema and a target schema according to an embodiment.
FIG. 59 is a diagram disclosing an example of a user interface for mapping a source schema and a target schema according to an embodiment.
Figure 60 is a flowchart showing an example of a method for providing an application service according to an embodiment of the present invention for converting data based on a source schema for EDI document data.

Below, embodiments that can solve the above problems and resolve technical inconveniences for transactions are disclosed.

When components of the embodiments are mentioned below, they can all be implemented with optimized hardware or software, unless specifically limited to physical devices.

FIG. 1 is a flowchart disclosing an example of a method for providing an application service according to an embodiment.

The method for providing an application service according to the disclosed embodiment allows multiple clients to obtain or download applications necessary for transactions or add or change desired functions through the platform.

The embodiment can receive a channel request for transmitting and receiving information from a client using a virtual isolated workspace (S100).

When a client connects to the platform, the system can provide the client with a virtual, isolated workspace.

A client may have workspaces that can receive separate services, but the hardware infrastructure of the systems providing each workspace may be common.

The system administrator or client can perform remote control and update of the system so that the client can receive the above services, and the system can be equipped with communication functions according to protocols linked to various standards.

A client can request a channel from the platform through which it can send and receive desired information, and the platform can allow the client to establish a channel.

Detailed examples of this are disclosed below.

The embodiment may provide a platform service that enables a client to create, change, save, or otherwise transform an application package in his/her workspace (S200).

A client may develop an application package or part of a package in a system such as an embodiment, and may trade related applications or software and operate a trade-related business.

Hereinafter, the term "application package" or "package" refers to a bundle of programs or files, including adapter packages that support protocols or services, resource packages required for program execution, and integrated packages that integrate multiple packages. In the examples below, an application package may also be referred to as a software package.

The system may provide various means or specialized computer languages that support mappings to various data formats and structures desired by clients. It may also provide applications and related tools to enable clients to modify application packages.

Detailed examples of this are disclosed below.

The embodiment can provide a service that controls service scale-out when the client uses an application package or another client receives application services in their workspace (S300). This step can be performed as needed to control scale related to service provision. The client can receive application services or operate the application services without interruption, depending on the provided system.

Detailed examples of this are disclosed below.

FIG. 2 is a drawing showing an example of providing application services to a client through a workspace among the disclosed embodiments.

This drawing is a conceptual diagram for explaining workspace and multi-tenancy among embodiments providing the disclosed application service.

The embodiment may provide a software-as-a-service (SaaS) to the user.

The embodiment may provide an application or SaaS-type software service used for transmitting and receiving information such as transactions between the parties.

In this drawing, the trading parties are represented as Client 1 (110), Client 2 (120), or Client 3 (130).

Clients (110, 120, 130) can transmit and receive various types of information, including business transactions, with their respective partners. In this case, the clients (110, 120, 130) can utilize the application service provision method described above.

An application service providing device according to an embodiment includes an instance system (1000) that provides an application including software in the SaaS format, and a manager system (2000) that provides an application service through the instance system (1000).

The manager system (2000) can provide a scale-out instance system (1000) to clients (110, 120, 130).

In the instance system (1000), an interface of a service provided by the manager system (2000) to clients (110, 120, 130) can be executed.

The manager system (2000) may include a manager server (2100) that connects and controls the instance system (1000) and a database (2200) that can store transmitted and received information and requirements of clients (110, 120, 130). The functions of the manager system (2000) are described in detail below.

The instance system (1000) provided by the manager system (2000) may include at least one node.

In the example of this drawing, node #0 (1100) can act as a service coordinator that provides application services and performs scale-out under the control of the manager system (2000).

In this example, the coordinator (1100), which is node #0, can control the scale of the system by being connected to worker nodes such as the first node (Node #1), the second node (Node #2), the third node (Node #3), and the Nth node (Node #N).

For example, connections between nodes can utilize interface protocols such as the HTTP protocol (hereinafter referred to as HTTP/REST) of a RESTful application programming interface (API). A RESTful application programming interface (API) can use HTTP to transmit and receive data between servers.

For example, a coordinator (1100) that is node #0 can transmit and receive data to and from each of the first node (Node #1), the second node (Node #2), the third node (Node #3), and the Nth node (Node #N) via HTTP/REST.

Similarly, Node #1 can send and receive data with other nodes (Node #0, Node #2, Node #3, and Node #N) based on HTTP/REST.

The coordinator (1100) can cause the software package to be installed on each node (in this example, the first node (Node #1) to the Nth node (Node #N)) according to a request for software package installation from the manager system (2000).

Each node can include a framework that allows creation of workspaces regardless of system type, as described below.

The coordinator (1100) can provide workspaces (1510, 1520, 1530) running on the framework of each node to each client (110, 120, 130).

Clients (110, 120, 130) may have isolated workspaces (1510, 1520, 1530) and may be provided with, modified or used applications or software packages through the isolated workspaces.

In this example, the first node (Node #1) can provide software package A and software package C provided by the framework within the first node (Node #1) to the client through the coordinator (1100).

The second node (Node #2) can provide software package A and software package B provided by the framework within the second node (Node #2) to the client through the coordinator (1100).

The third node (Node #3) can provide software package B and software package C provided by the framework within the third node (Node #3) to the client through the coordinator (1100).

The manager system (2000) can stably provide each of the isolated workspaces (1510, 1520, 1530) to the clients (110, 120, 130) through the instance system (1000).

For example, client 1 (110) can independently use workspace (1510).

Client 1 (110) can transmit and receive necessary data in its workspace through a channel established with the coordinator (1100). For example, Client 1 (110) can receive necessary software packages A and C from the coordinator (1100) through an HTTP channel in workspace A (1510). Detailed examples of establishing channels between the workspace and the coordinator (1100) or between the coordinator (1100) and each node will be described later.

Client 2 (120) can receive the required software packages A and B from the coordinator (1100) via an HTTP channel, for example, in workspace B (1520).

Similarly, client 3 (130) can receive the necessary software packages B and C from the coordinator (1100) via an HTTP channel in workspace C (1530).

The instance system (1000) can provide a virtualized system so that clients (110, 120, 130) do not need to be aware of which node within the instance system (1000) provides the desired software package in their workspaces (1510, 1520, 1530).

Each node (Node #1, Node #2, Node #3, Node #N) that stores and provides software packages by a coordinator (1100) can store software packages that can be provided to workspaces (1510, 1520, 1530). That is, multiple nodes (Node #1, Node #2, Node #3, Node #N) can be virtualized to provide workspaces (1510, 1520, 1530) that are isolated from each other.

Each of the nodes (Node #1, Node #2, Node #3, Node #N) contains a framework, and can control the download and execution of software packages from a software package repository (not shown) within each framework. This will be described in detail below.

The software package required for workspace A (1510) used by client 1 (110) can be stored in at least one node among each of the nodes (Node #1, Node #2, Node #3, Node #N).

In this example, software package A is stored in the first node (Node #1) and the second node (Node #2), but may also be transferred to and stored in other nodes (Node #3, Node #N) by scaling out the coordinator (1100).

Software package B is stored on the second node (Node #2) and the third node (Node #3), but may be transferred to and stored on other nodes (Node #1, Node #N) by scaling out the coordinator (1100).

Similarly, software package C is stored in the third node (Node #3) and the first node (Node #1), but may be transferred to and stored in other nodes (Node #2, Node #N) by scaling out the coordinator (1100).

In this way, software packages can be distributed and installed across multiple nodes. The coordinator (1100) stores information on which nodes the software package is installed, performs routing for software package requests when necessary, and performs task scheduling functions for the nodes it manages.

Accordingly, clients (110, 120, 130) can obtain software packages from their respective virtualized and isolated workspaces (1510, 1520, 1530) without having to know which node the desired software package is stored on due to the scale-out of the coordinator (1100).

The manager system (2000) can control the coordinator (1100) to provide application services so that clients (110, 120, 130) can obtain desired software packages.

Nodes serve as worker nodes on which the adapter package or software package described below is installed and executed. In the instance system (1000), worker nodes can be automatically or manually scaled out and expanded as needed under the management of the manager system (2000).

Figure 3 is a conceptual diagram disclosing layer-by-layer elements for providing application services according to an embodiment.

The application service providing device according to the embodiment can be controlled and managed by the manager system (2000).

The manager system (2000) can provide application services, such as EDI services, using an on-premise system or a cloud system. Detailed examples of services provided by the manager system (2000) are described below.

The computing system may include at least one of an on-premises system or a cloud system.

A computing system may also include a virtualization layer, such as a container or virtual machine (VM), that can virtualize computing resources.

This drawing illustrates a case where a virtualization layer is included, with the virtualization layer indicated by a dotted line.

For example, computing systems can provide containers as a virtualization layer. Containers can use the host's resources as needed to run applications on top of the host operating system (OS). Container images can be used to rapidly develop and deploy applications.

The computing system may include a framework layer (1700) that provides a framework. The framework may enable various applications to run through an application programming interface (API) (1610, 4100).

The workspace (1500, 3000) or the interface governance platform (4000) is located on the application programming interface (API) (1610) or the governance API (4100), respectively, and various applications can be run on the application programming interface (API) (1610, 4100).

The client (100) can receive application services, i.e., software packages, provided by the manager system (2000) through a system having layers as exemplified in this drawing.

For example, a client (100) can use services such as an EDI application (EDI App.) through an isolated workspace (1500). In this example, the client (100) can use applications or services such as EDI and other application services (App.), message services, web services, protocol adapter services, data transformation services, monitoring services, and security services through the workspace (1500). The applications or services on the workspace (1500) are described in detail below.

A partner (200) may be an actual transaction partner of a client (100) or another transaction entity related to a transaction and may use application services through the workspace (1500) or receive application services such as EDI services provided by the client (100).

When a client (100) conducts a transaction through an application related to an EDI service, a partner (200) can conduct a transaction through an EDI service application provided by the client (100).

The manager system (2000) can provide an environment in which clients can develop applications necessary for their transactions.

The manager system (2000) can develop and test applications in the development workspace (3000) and provide application services developed through the workspace (1500). In addition, the manager system (2000) can manage the computing environment that provides the development workspace (3000) to a client (100) or partner (200), and enable the client (100) or partner (200) to develop necessary applications in the development workspace (3000).

This development workspace (3000) may include a development tool application that can develop applications, a billing application (payment/billing) that determines the usage and billing system for the developed applications, an app store (app. Store) that can sell the developed applications, and a back-office application that supports and controls these functions.

For example, a client (100) or partner (200) can develop, modify, and test applications through the development workspace (3000). The client (100) or partner (200) can develop applications or software packages on its own in the development workspace (3000) as well as applications provided by the manager system (2000).

Additionally, the client (100) can provide applications developed through the development workspace (3000) to other clients or partners through the app store (3000) illustrated in the drawing.

Partner (200) and manager system (2000) can also use the system provided by the client (100) to develop, test, utilize and provide services for software packages.

The manager system (2000) may also provide inspection and control of the client system through the interface governance platform (4000) on the solution API (4100). These services are disclosed in detail separately.

Below, detailed examples of a client (100) receiving or providing a service using a software package through a workspace (1500) are described.

FIG. 4 is a drawing disclosing a specific example of an application service providing device according to an embodiment establishing a channel between an instance and a client or partner.

According to the concept disclosed above, the application service manager (2100) can enable a client or partner (300) to provide, use, and modify an application through the instance system (1000). The instance system (1000) can include a coordinator (1100) and an Nth node (1300), which is an arbitrary node.

The application service manager (2100) can distribute information for installing an agent (350) to a client/partner (300). For example, the information for installing an agent (350) can include agent setting information, key information for agent setting, resource management information, user management setting information, etc.

For example, agent configuration information may include information such as the time to synchronize channel information, a timeout for HTTP requests, the key value of the session key associated with the installed browser, and the path the agent needs to send and receive related information.

A channel is configured to use a service provided by the application service manager (2100). It can be described as a component for connecting to a package, such as an adapter package. Examples related to this are described in detail below.

The client/partner (300) may have an agent (350) installed, and the agent (350) may collect resource management information, connection information, user information, etc. of the client/partner (300). If necessary, the agent (350) may access the database or file system of the client/partner (300).

An agent (350) can request a software package from a coordinator (1100) of an instance system (1000). In this case, the agent (350) can request a channel service for receiving the software package from an agent adapter (1350) of the coordinator (1100). Here, an HTTP request can be used for the channel service requested by the agent (350) to the agent adapter (1350).

For example, when an agent (350) of a client/partner (300) transmits a request to a preset HTTP URI, the coordinator (1100) can allow HTTP traffic coming into a specific port, i.e., an inbound HTTP connection, and convert this HTTP service into a channel service that is transmitted to the agent adapter (1350) of the Nth node (1300), which is a worker node.

Information for installing the agent (350) already includes path information that can access the instance system (1000).

When an agent (350) is installed on a client/partner (300), the administrator of the client/partner (300) can set management information, user information, etc. of the client/partner (300) system managed by the agent (350), and can also set a synchronization time with the agent adapter (1350) of the Nth node (1300).

The application service manager (2100) can set setting information for the agent adapter (1350) installed in the instance system (1000) in relation to the registered agent (350) and information on whether synchronization with the registered agent (350) is activated.

The application service manager (2100) can set outbox slot information within a message box for storing information transmitted by the registered agent (350) and inbox slot information within a message box for storing information received by the registered agent (350).

The application service manager (2100) stores the information transmitted by the agent (350) and the information received by the agent (350) in the outbox slot and the inbox slot within the message box (2110), respectively, according to the information set as above. The slot within the message box is a logical division concept that stores a data processing unit, and the message box can store and output a data processing unit like a queue.

Meanwhile, the application service manager (2100) can also set authentication key information that enables the registered agent (350) and agent adapter (1350) to perform authentication.

In this way, when the agent (350) is registered to the client/partner (300) and the agent adapter (1350) is set to the instance system (1000), the agent adapter (1350) can be connected to the resource set to the agent (350).

And, according to the information set from the agent (350), related information or data can be transmitted and received with the agent adapter (1350).

In this drawing, the channel through which the agent (350) transmits information (outbox) output from the resource of the client/partner (300) according to a set cycle is indicated as a send channel. In addition, the channel through which the agent (350) receives information (inbox) transmitted from the agent adapter (1350) is indicated as a receive (receive/polling) channel.

The agent (350) can send and receive data requested from the agent adapter (1350) through a set send channel and a set receive/polling channel.

FIG. 5 is a diagram disclosing an example of managing channels and providing services in a distributed system according to an embodiment.

As illustrated, nodes within the instance system (1000) can transmit and receive data via channels to provide services. A channel is a general term for a path that calls data or packages for providing services, or searches for a node on which a previously registered channel is running.

Here, an example is disclosed in which a coordinator (1100) of an instance system (1000) manages packages installed on nodes in a distributed environment through channel connections.

The coordinator (1100) can store channel information that can connect each worker node and information about packages stored in each worker node.

For example, the coordinator (1100) can register and store information about packages stored in worker nodes (1110, 1120). The coordinator (1100) can register and store information about adapter package A and integration package stored by the worker node (1110) of the first node (Node #1), and can register and store information about adapter package B stored by the worker node (1120) of the second node (Node #2).

The coordinator (1100) can receive service requests related to packages from clients or partners. As described above, this example illustrates a case where the service request is received via an HTTP request containing URL information.

The coordinator (1100) can set up a service channel for worker nodes that are registered and mapped to the coordinator (1100) based on URL information included in the HTTP request.

As in the example here, the coordinator (1100) establishes an HTTP service channel based on an HTTP request containing URL information from a client or partner. The coordinator (1100) can call adapter package A provided by the first worker node (worker node #1) (1110) through the established HTTP service channel.

Since clients or partners use isolated workspaces provided by the coordinator (1100), the versions of packages within each workspace of clients (or partners) may be different and different versions of adapter packages may be used.

Adapter package A requested by the client can be called through an HTTP service channel from the first worker node (worker node #1) (1110) according to the information registered in the coordinator (1100).

The first worker node (worker node #1) (1110) can provide the registered adapter package A according to the HTTP service channel.

If a client or partner develops an application package in that workspace, they may need an integration package that includes Adapter Package B.

The coordinator (1100) knows that the first worker node (worker node #1) (1110) stores the integrated package and the second worker node (worker node #2) (1110) stores the adapter package B based on the registered information.

The coordinator (1100) can search for an integrated package including adapter package B in the first worker node (worker node #1) (1110) through an adapter function channel. If adapter package B is not included in the integrated package stored in the first worker node (worker node #1) (1110), the first worker node (worker node #1) (1110) can call adapter package B stored in the second worker node (worker node #2) (1120) through a channel connection between the worker nodes.

Then, the second worker node (worker node #2) (1120) can provide the called adapter package B, in which case the coordinator (1100) can register a channel providing adapter package B to the adapter function channel so that adapter package B is provided together with the integrated package.

In this disclosed embodiment, multiple packages can be distributed and installed across multiple nodes. To enable communication between packages or to call a specific adapter package from outside the instance system, the coordinator (1100) can manage and store channels that search for, call, or register the corresponding package on worker nodes capable of providing package services.

The agent adapter (1350) of the coordinate (1100) instance system (1000) can set up transmission and reception channels from the agent (350) as exemplified. The agent adapter (1350) can set up a specific agent and channel using information related to the channel, such as the agent's identifier and channel period.

In this way, the coordinator (1100) can manage various pieces of information so that requested package-related services can be distributed and performed across worker nodes. While the HTTP service channel is exemplified above, packages can also be delivered via a file transfer channel such as FTP.

The coordinator (1100) may store adapter packages that are distributed and executed across multiple worker nodes in shared memory (not shown) or storage.

Additionally, the coordinator (1100) can store and manage data such as logs related to adapters used by multiple clients.

FIG. 6 is a drawing disclosing an example of managing setting information of a package installed according to an embodiment.

In the example of this drawing, the coordinator (1100), the mth node (node #m) (3110), and the nth node (node #n) (3210), which are distributed systems within the instance system (1000), may each include configuration storage units (1115, 3115, 3215) within the nodes.

The application service manager (2100) of the manager system (2000) can store various configuration information (rectangles) related to the package. The stored configuration information can include various configuration information required when the package is executed on each node.

The application service manager (2100) can store the configuration information of a package in a database (2200). The application service manager (2100) can obtain the configuration information of a package from a specific node, in this example, node #m (3110), or store the configuration information of a package requested externally in the database (2200).

The coordinator (1100) can store configuration information of a package managed by the application service manager (2100) in its configuration storage (1115). The application service manager (2100) can manage and store configuration information of the package through a control screen, etc.

The m-th node (node #m) (3110) and the n-th node (node #n) (3210), which are wicker nodes within the instance system (1000), can receive configuration information of related packages from the configuration storage (1115) of the coordinator (1100) and store them in their respective configuration storages (3115, 3215).

In this example, the nth node (node #n) (3210), which is a worker node, can synchronize the configuration information of the package with the configuration information of the package stored in the configuration storage (1115) of the coordinator (1100). This synchronization may be performed periodically, or may be synchronized at different cycles depending on the settings.

When the nth node (node #n) (3210), which is a worker node, needs to execute a package, it can execute the package using the configuration information synchronized and stored in its configuration storage (3215).

The client/partner can change and save the package setting information of the worker node node m (node #m) (3110) through the package setting screen of the coordinator (1100), etc.

When the package setting information of node #m (3110), which is a worker node, is changed, the changed setting information of the package can be transmitted to the application service manager (2100).

Again, the application service manager (2100) can store the changed configuration information of the package transmitted from the node #m (3110) in the database (2200).

FIG. 7 is a diagram showing an example of managing and using packages according to a workspace of an embodiment of the disclosure.

Clients can create, run, and modify multiple packages in an isolated workspace.

For example, a client can execute an adapter package in a workspace, which can use configuration information stored in a configuration repository. However, in some cases, the package may also reference resource files in addition to the configuration information stored in the configuration repository.

Resource files can be installed in the workspace as mapping programs, a type of resource package. Resource files can be accessed using resource paths when executing packages, such as adapter packages, to enable the adapter package to run.

According to the disclosed embodiment, both development or testing and operation of packages are possible in the workspace.

Therefore, according to an embodiment, resource files can be provided by separating a workspace for operation and a workspace for development.

In the example of this drawing, when developing an adapter package in the development workspace (1510), the adapter package can be used as a program that can read and write resource files. In this case, the resource file, which is a mapping program, can be accessed by specifying it as a writable shared resource path.

On the other hand, when running an adapter package in an operational workspace (1520), the resource file may be provided as a resource package that the adapter package can only read but not write. In this case, the adapter package can reference the resource package to install and access it, but cannot modify the resource files within the resource package.

FIG. 8 is a diagram disclosing an example of mapping EDI information as a type of application service according to an embodiment.

The disclosed embodiments can provide not only various application services but also a platform environment for developing various application services.

Below, an example of such application service is described, using EDI service as an example. As those skilled in the art will readily appreciate from the disclosure, the embodiments can be used to develop or provide a variety of application services, and are not necessarily limited to EDI services.

As a type of application service, EDI requires various types of transactions, parties, and transaction formats across industries. Therefore, utilizing examples that address the complex and diverse transaction patterns of each industry enables efficient transactions, making it highly effective in stimulating industrial transactions.

This diagram illustrates an application service that converts various information or documents required for EDI services between trading parties.

EDI has a wide variety of formats, each with specific rules and regulations for each industry. EDI documents must be created and processed according to these formats to complete a transaction. EDI services vary across various industries, including e-commerce, transportation, logistics, finance, and insurance. EDI is standardized by international standards organizations such as ISO and is regulated and managed by UN/EDIFACT (United Nations/Electronic Data Interchange for Administration, Commerce, and Transport) and ANSI (American National Standards Institute) X.12.

Depending on the nature of the transaction, which involves ordering and supplying, different forms of documents containing different data or information may be used, and the systems used by the parties to the transaction may also be different.

For EDI service, documents between two trading parties must be mapped.

This drawing example conceptually discloses an advanced mapping engine, a program that transforms documents containing data into a general-purpose system to provide EDI services.

For example, a trading partner may provide an EDI document and EDI schema required for the transaction. This data can be decoded into unmarshal data by decoding the bytes or strings contained in the EDI data (i.e., the EDI document) according to the input schema.

A mapping engine may include reference information for mapping schemas based on the data to be converted and the schemas of the data being converted. This mapping reference information is referred to herein as a mapping script.

The mapping criteria information can be in script format to convert the unmarshalled data into a document of a different format targeted at other purposes.

A mapping engine can convert EDI data and EDI schema decoded data (unmarshal data) into a file of a specific format that can be used as an interface to a general document (here, a JSON file as an example) and into a schema for the file of the specific format (here, a JSON schema as an example).

In more detail, the EDI format of the SEF (Standard Exchange Format) standard can be used as an EDI schema, or an EDI format such as EXF (EDI Exchange Format) can be used.

The changed format file can be a flat file, JSON, XML, etc.

When marshalling or unmarshalling each file type for a file in a changed format, it can be converted into a schema file defined by annotations. In other words, the marshalling or unmarshalling result can be obtained as a schema that defines the type corresponding to the data to be converted and the annotation corresponding to the specific data type.

The embodiment may provide a user with a graphical interface that enables the user to create a schema through such a mapping engine and write a mapping script, which is mapping reference information.

FIG. 9 is a diagram showing an example of providing an application service using an integrated package according to an embodiment.

According to an embodiment, a client (310) can provide an application service, such as the example disclosed, to a desired partner (320). The embodiment can not only provide a service from the client (310), but also enable the client (310) to directly provide a customized service to a desired partner (320) using the embodiment.

Here, an EDI service among application services is described as an example. In order for a client (310) to transact with a partner (320), the embodiment may provide a coordinator (1100) and worker node (1300) included in the instance system.

The application service manager (2100) can provide and manage an instance system so that a client (310) and a partner (320) can exchange information necessary for a transaction through the instance system.

As disclosed, the client (310) has an agent (not shown) installed, and can request EDI information, which is information required for a transaction, through the agent. In this case, the request for EDI information can be transmitted as HTTP traffic.

The coordinator (1100) of the instance system maps an HTTP request containing EDI information transmitted from a client (310) to a designated channel and transmits it to the corresponding worker node. In the example above, the coordinator (1100) disclosed an example of querying and managing channel registration with an HTTP request containing URL information. The coordinator (1100) converts the HTTP request into a channel service and transmits it to the agent adapter (1350) of the corresponding worker node (1300) capable of receiving the channel service.

The agent adapter (1350) transmits the requested EDI information through the channel service to the message box (2110) of the application service manager (2100).

The message box (2110) of the application service manager (2100) can store EDI information transmitted from the agent adapter (1350) in the client inbox (2111).

The message box (2110) of the application service manager (2100) transmits the requested EDI information to the integration package (1380) of the worker node (1300).

Here, the integration package (1380) is a bundle of integrated development items, including various development flows and Java or script programs. The integration package (1380) allows for the combined use of these development items and can address integrated requirements.

The integration package (1380) can implement various requirements that can be traded between the client (310) and the partner (320) by exchanging information with the message box (2110), adapters of the worker nodes (1350, 1370, 1390) and the channel service of the coordinator.

The integration package (1380) can address user requirements by creating and registering routing for exchanging necessary information within the package when a specific channel is called according to a distributed channel service.

The elements and usage examples for the integration package (1380) are described in detail below.

The integration package (1380) can transmit EDI information stored in the client inbox (2111) of the message box (2110) to the mapping adapter (1370).

The mapping adapter (1370) unmarshalls the EDI information of the client (310) received from the integration package (1380) and outputs it as EDI conversion data mapped to information required by the partner (320).

When the integration package (1380) receives the EDI conversion data output by the mapping adapter (1370), it can transmit and store it in the partner outbox (2113) of the message box (2110) and forward it to the EDI adapter (1390).

The EDI adapter (1390) can convert EDI conversion data output from the integration package (1380) or stored in the partner outbox (2113) into a standardized format, such as UN/EDIFACT or ANSXI X.12.

The EDI adapter (1390) may also transmit and store standardized EDI conversion data in the partner outbox (2113) of the message box (2110).

The coordinator (1100) can receive standardized EDI conversion data stored in the partner outbox (2113) of the message box (2110) or converted by the EDI adapter (1390) through the channel service, and convert it into HTTP traffic and transmit it to the partner (320).

As a result, the partner (320) can receive standardized EDI conversion data for the EDI information transmitted by the client (310). When the partner (320) transmits its own EDI information to the client (310), the data can be transmitted according to a similar process.

Accordingly, clients (310) and partners (320) can easily use application services such as EDI services according to the disclosed embodiments, and can easily conduct transactions according to the standardized format even if they do not know the standardized format or do not accurately understand the documents and information requested by the transaction counterparty.

A client (310) or partner (320) can develop or use multiple software packages in their workspace and link them to an integrated package (1380).

The embodiment can be provided through a very easy interface for developing such packages and connecting them with existing packages, and the developed packages can also be sold, shared, or provided separately.

FIG. 10 is a drawing illustrating an example of an interface of a platform according to an example of providing an application service disclosed.

This diagram illustrates the interface provided by the platform when a user accesses the platform, for example, to provide application services.

When a client connects to a system that initiates a platform, the platform may present a user interface menu associated with the user's dedicated workspace.

A client can access the instance system through an interface platform provided by the manager system as illustrated in this drawing, or by using HTTP including a URL.

In the example of this drawing, the interface platform provided by the manager system may provide options for a user-specific workspace (151), a message box (152), file transfer (153), a message sent to a mobile terminal (SMS) (154), and information on the corresponding standard mapping if the information exchange involves EDI (155).

The workspace (151) is a menu that allows the client to use his/her own workspace, and the message box (152) stores messages related to the client.

File transfer (153) can check the file transfer method or history sent and received through the instance system.

Users can check the packages they use or develop (161) or the packages they have purchased (162) by selecting the user interface menu.

FIG. 11 is a diagram illustrating another example of an interface of a platform according to an example of providing an application service disclosed.

This diagram illustrates the user interface menus that can be viewed when a client accesses a platform providing application services initiated by the client and selects their workspace.

The client can check and use the workspace (171) it created, the instance system (172) related to the workspace, the creation date for each workspace (173), the description information of the workspace (174), whether the workspace is activated (175), and the services (176) and packages (177) related to the workspace.

The following describes an embodiment that provides an application capable of interoperability with different systems, when the application connects different systems. Software or applications developed through the workspace of the embodiment can be shared and used by multiple clients. If the client and partner use different systems, applications developed by the client (or partner) must be available on the partner's (or client's) system.

The instance system according to the embodiment can provide a framework for integrating these different systems, and the embodiment is disclosed as follows.

FIG. 12 is a drawing disclosing an example of an application service providing device according to an embodiment providing a framework that can integrate different systems.

The application service providing device according to the embodiment may include a framework that provides applications executable on different systems. Therefore, this integrated framework can provide applications that enable users of different systems to connect with each other, making it efficient and ideal for providing EDI services, such as the ones exemplified above.

This diagram illustrates an integrated system architecture as a framework capable of integrating different systems. The integrated system architecture provided by the framework of the embodiment includes one or more route engines.

The route engine provides routes that connect endpoints, which are different systems, and processors, which are tasks performed between endpoints.

Routes can describe the interface between systems, and in this example, the route engine provides routes 1, 2, …, N.

A processor refers to data processing that must be performed between transmitting and receiving systems, i.e., endpoints. In this example, a router processor and a message filter processor are exemplified.

A component refers to an adapter of a transmitting and receiving system to be linked. In this example, the integrated system architecture provides an example of connecting different systems by providing a unified interface to endpoints using components such as files, JMS, and HTTP.

A component that gets or receives data from (or is called by) a component is called a consumer, and a component that calls, transmits, or retrieves data from a component is called a producer.

A message is data exchanged for system communication, and can include a body, header, and attachments.

An exchange is a container that holds messages exchanged between systems. It is an object that is created when the route flow begins and its life cycle lasts only until the flow ends.

This integrated system architecture allows for the creation of applications that can be used across different systems and developed as an integration package. An example of this is the integration package (1380) illustrated in the example above.

An integration package developed based on an integrated system architecture can provide an integration flow that can resolve integration requirements by linking with services or adapter packages provided by a platform according to an embodiment.

An integration package implements the necessary processes within the flow of the integrated system architecture and can provide scripts or Java programs capable of various data transformations.

Clients (or partners) can create integrated packages necessary for their service provision using the integrated system architecture exemplified above based on the platform according to the embodiment.

The platform according to the embodiment can also provide an environment in which a client (or partner) can very easily develop an integrated package that implements an integrated flow using graphical coding.

Below, an environment in which an integration flow can be developed as an integration package provided by the integrated system architecture of the platform according to an embodiment is exemplified.

A platform according to an embodiment of a device providing application services can provide a graphic-based development environment using a library.

Clients (or partners) can use the examples to develop graphical integration flows, which can broadly include five functions.

Here, the five functions included in the integration flow are referred to as connectors, services, processors, control flows, and modifiers. These names are merely examples, and each function is described in detail below.

Figure 13 shows an example of graphically coding connectors and services among integration flow functions when developing an integration flow based on an embodiment.

In this drawing (a), the connector may include a From graphic element indicating the start of a route in the integrated system architecture illustrated above.

A connector can include a To graphic element that defines external actions, such as calling a service or adapter, storing data, etc., when a flow developed in a development environment is implemented.

As illustrated in this drawing, an integration flow can be developed using a connector that can express the input/output (From/To) of a route in graphical coding in a graphical development environment provided by the embodiment.

To explain the connector in a little more detail, the connector can call specific data as a consumer (From Connector) and, as a producer, provide data processed through the flow to outside the integration flow (To Connector).

A consumer can be a direct caller that calls a route within an application package when an integration flow calls specific data (From Connector), or a timer that periodically calls data by a task scheduler.

There may also be other cases where the integration flow calls (From Connector) specific data, such as a channel that registers a route as a channel and starts a route when the channel is called, a message box that periodically checks for unprocessed messages and starts a route if there are any, or an FTP that checks if there are documents in the registered FTP service path and starts a route if there are documents.

These consumers can include options such as a Route ID within the unified package, Auto Start, which indicates whether the route should be started at package installation time, and Start Order, which indicates the start order of the corresponding routes upon package installation.

A producer represents the external output action (To connector) of a connector as a result of the execution of an integrated flow. Producer types include "direct," which refers to calling another direct route within the same application package, and "message box," which refers to saving a document in a message box. Additionally, there may be "channel," which refers to calling another channel within the workspace as a producer, or "FTP," which refers to transferring a document to a registered FTP service.

Therefore, as in the example of this drawing, an integration flow can be developed using a connector that includes the input/output (From connector/To connector) coding elements of the route with graphic coding.

(b) of this drawing shows an example of graphically coding a service among the integration flow functions when developing an integration flow based on an embodiment.

An integration flow that can be developed graphically according to an embodiment can be coded based on a visual interface using service blocks.

In the example of this drawing, the service block may include a getNextControlNumber element, an isDuplicatedControlNumber element, a putUsingControlNumber element, a remoteCache element, etc., which are provided graphically.

The getNextControlNumber element means issuing a new control number, and the isDuplicatedControlNumber element is an element that checks whether the control number is duplicated.

In this drawing, you can define whether the control numbers are duplicated (True) or not (False).

Among the service blocks in developing an integrated flow, the putUsingControlNumber element stores the used control number in storage and uses it to check for duplication, and the remoteCache element exemplifies accessing the workspace's cache service.

Therefore, integration flows can be graphically coded using service blocks such as the example in this drawing.

Figure 14 shows an example of graphically coding the processor, control flow, and modifier among the integration flow functions when developing an integration flow based on an embodiment.

An integration flow that can be developed graphically according to an embodiment can be coded based on a visual interface using processor blocks.

In example (a) of this drawing, the processor block may include a log element, a process element, an xslt element, a groovy element, and a delay element, which are provided graphically.

The log element leaves the necessary information in the package log when the flow is executed. The package log can be checked by the adapter that monitors the execution status of the package.

The process element allows you to perform custom processing by calling the method of a Bean registered in an uploaded Java (Jar) package item.

The xslt element allows you to select an XSLT package item to perform an XSLT transformation.

The groovy element allows you to call a script by selecting a Groovy package item.

The delay element can be used to delay the flow's route for a short period of time.

Therefore, integration flows can be graphically coded using processor blocks such as the example in this drawing.

An integration flow that can be developed graphically according to an embodiment can be coded based on a visual interface using a control flow block.

In example (b) of this drawing, the Control flow block may include a split element, a for element, a while element, an xslt element, an If or Switch-Case element, and a Try-Catch element, which are provided graphically.

The split element records the necessary information during flow execution in the package log, which can be checked by the adapter that monitors the package execution status. The split element is a function that can split a single integrated document (Exchange) into multiple Exchanges for processing, and can support Delimiter, XPath, and Bean methods.

The for element is used when processing a message multiple times, and provides the ability to process it in a different way for each iteration.

The While element provides the ability to activate a while loop that loops until a Simple expression evaluates to false or null.

The If or Switch-Case elements provide the ability to route messages to the correct destination based on the content of the message exchange.

The Try-Catch element can support the same exception handling functionality as Java's Try-Catch.

Therefore, the integration flow can be graphically coded using the example control flow block.

An integration flow that can be developed graphically according to an embodiment can be coded based on a visual interface using a modifier block.

In example (c) of this drawing, the modifier block may include a loadProperty element, a setProperty element, a setHeader element, a setBody element, a removerHeader element, and a removeProperty element, which are provided graphically.

The loadProperty element provides the ability to retrieve a settings node from a settings store and store it in an Exchange Property.

The setProperty element can provide the ability to assign a value to an Exchange Property.

The setHeader element can provide the ability to specify a value for an Exchange Message Header.

The setBody element can provide the ability to specify values for the Exchange Message Body.

The removerHeader element can provide the ability to remove a value from an Exchange Message Header.

The removeProperty element can provide the ability to remove a value from an Exchange Property.

Integration flows can be graphically coded using the example modifier blocks.

Below, an example is disclosed that can distinguish users such as clients and isolate each workspace according to the embodiment disclosed above.

If the software packages provided to clients using the workspace are identical and the same software image is run on each client, then all versions and types of software packages must be prepared and provided for each client.

However, according to the embodiments disclosed below, even if application services are provided using the same software package, resources can be used efficiently and isolated services can be provided for each workspace used by the client.

A detailed example is as follows:

The above example discloses a channel through which clients or partners can send and receive relevant information based on a platform provided by the manager system.

Below, we present an example of how a client and partner can exchange data while maintaining information security. The example above illustrates an example of an agent within a client or partner and an agent adapter within a platform provided by an instance system exchanging information.

Accessing a client or partner without installing an agent in this way can cause security issues on the client or partner's system. To avoid this issue, the client or partner can install an agent. Furthermore, the manager system can easily perform patches or upgrades using the agent installed in the client or partner.

Additionally, the agent adapter can perform protocol conversion or data conversion for data transmission and reception, thereby converting the channel transmitted from the agent or the protocol for data transmission and reception to facilitate communication.

Agents can manage connection information for installed clients or partner systems. In this case, agents can configure connection information for resource access on the client or partner system. For example, agents can configure databases, file systems, user information, resource access, or management information for the installed system. They can also poll information from the agent adapter according to set cycles or conditions.

Agent adapters within the platform provided by the instance system can be installed on the instance system as application packages. The agent adapter can be configured to collect or store information from registered agents installed on client or partner systems according to set cycles or conditions.

The coordinator of an instance system can establish a channel through which agents can connect. When a request is received from an agent on the established channel, the coordinator can map the channel and forward it to the agent adapter on the worker node.

When installed on a client or partner system, an agent may have various configuration information. For example, an agent application may have configuration information that includes agent-related configuration information, security key information related to agent execution, resource management configuration information, and user management information.

The platform of an instance system can provide a connection interface through which clients or partners can download and run agent applications.

Below we illustrate the user interface of an agent or agent adapter and describe an example of controlling it.

FIG. 15 is a diagram illustrating an interface of an agent when an agent provided on a platform of an instance system according to an embodiment is executed.

A client or partner can run an agent application by installing the agent application provided by the platform of the instance system.

This diagram illustrates the agent's interface when the agent application is running and the agent is run by an administrator or user.

The client or partner's administrator can check the status menu (2115) that indicates the current status through the agent.

The administrator can check agent public key information, information on synchronizing agents and agent adapters, status messages in case of synchronization errors, etc. from the status menu (2115).

And the administrator can obtain information about whether the channel set in the agent adapter is connected to the resource, the connection time, and the connection status from the status menu (2115).

Client or partner administrators can use a menu (2120) to manage their own resources that can be managed via agents. In the example of this diagram, the resource management (2120) menu represents resources that can be included and managed in the client or partner system, such as databases, directories, SAP systems, or IBM MQ systems. Administrators can manage resources through the resource management (2120) menu and set location information, connection information, and connection paths for each resource.

Additionally, the client or partner administrator can manage agent users through the agent using the user management menu (2130). The administrator can manage agent users and set permissions for each user using the user management menu (2130).

FIG. 16 is a drawing illustrating an example of an interface of an agent adapter provided on a platform of an instance system according to an embodiment.

Clients or partners can utilize the agent adapter provided by the instance system's platform. Clients or partners can register agents exemplified in the agent adapter provided by the instance system's platform.

This drawing illustrates an interface of an agent adapter, according to which a client (or partner) can register with the agent adapter an identifier (2210) of an agent installed on a partner (or client) system that can communicate with each other, a name of the agent (2220), a description (2230) that can describe the agent, etc.

The interface of the agent adapter may include a message box slot (2240) for storing documents or information received by the agent, and a message box slot (2250) for storing documents or information transmitted by the agent.

And the agent adapter interface may include agent public key (2290) information for agent authentication. Here, the hash value of the public key is exemplified as agent public key information.

The agent adapter interface includes a means (2295) for activating connection or synchronization with a registered agent as described above. This example discloses an example in which the agent adapter transmits and receives information with an agent through a button (2295) that is activated to synchronize with the agent.

As above, the agent adapter can register the agent's configuration information, and the agent's configuration information can be stored in the configuration storage of the worker node where the agent adapter is installed.

In this way, agent adapters can be used to register or modify agent configuration information installed on clients or partners. Agents configured through agent adapters can connect to resources on the system where they are installed and send and receive data with the instance system.

As explained, a transmission channel refers to a channel that periodically retrieves information from resources of a partner (or client) system and transmits it to the client (or partner) system. A reception channel refers to a channel that stores information received from the client (or partner) system in a set location and format on the partner (or client) system.

Therefore, setting up a transmission channel here means setting up information or documents to be retrieved from an agent installed on the client or partner's system and stored in a message box.

And the setting of the receiving channel means the setting of storing information or documents received by the agent adapter through the channel setting in a certain location of the client or partner's system.

Below, examples of channel configuration are detailed. Agent adapters can control the transmission and reception of information or documents through channel configuration.

FIG. 17 is a diagram illustrating another example of an interface of an agent adapter provided on a platform of an instance system according to an embodiment.

The channel types configured for agent adapters installed on nodes of an instance system can vary, and different settings can be configured for transmit and receive channels in the agent adapter. The channel type configured for each adapter can be the same as the type of resource managed by the agent.

This diagram illustrates the resources managed by an agent. In the example shown, the agent manages a database, a directory, an SAP system (SAP JCO) within the system on which it is installed, and an IBM system (IBM MQ) within that system.

In this case, the agent adapter can set the channel type to JDBC (Java Database Connectivity) (2310), a Java API that can connect to the database, for the database, and can set the channel type to FILE (2320) that can be sent and received to the directory.

Here, the agent adapter can set the Java Connector (JCO) (2330) as the channel type for the SAP system, and the Message Queue (MQ) (2340), which is a network software, as the channel type for the IBM system.

Here, we have used SAP and IBM systems as examples, and even if the client or partner system includes other systems, you can set the channel type related to that system.

FIG. 18 is a diagram showing an example of an agent adapter of a platform of an instance system according to an embodiment setting up a transmission and reception channel.

This example illustrates setting up a transmit channel (top) and setting up a receive channel (bottom) that the agent adapter transmits.

In this example, when setting up a transmission channel (top), it is assumed that the agent ID of the agent that the agent adapter transmits to is test-agent, the channel ID is file-send, the adapter type is file (FILE), the transmission direction (Direction) is send (SEND), and the adapter version (adapter version) is 1.0.

Agent adapters can set the polling schedule in seconds or cron, and can set the channel depending on the adapter type.

The illustrated example can set source information (2410), which is the location information of a file for a transmission channel. Here, a directory name (file-send), a file name or extension (*.txt), a file encoding type (UTP-8), etc. can be set as the source information (2410).

And after transmitting information through a transmission channel, processing mode (2420), time information for checking whether there is any change on the set channel (modification check wait millis), and maximum file size information (2430) can be set.

In this example, when setting up a receiving channel (bottom), the agent ID of the agent receiving from the agent adapter is assumed to be test-agent, the channel ID is assumed to be file-recv, the adapter type is assumed to be file (FILE), the transfer direction is assumed to be transfer (RECV), and the adapter version is assumed to be 1.0.

This example illustrates that the location information (file-recv), file name or extension (*.txt), file encoding type (UTP-8), etc. (2450) of the file to be received through the receiving channel can be set.

FIG. 19 discloses an example of transmitting EDI data, which is transaction information, using a platform of an instance system according to an embodiment.

The agent adapter (1350) provided by the instance system according to the embodiment can exchange information with the system of the agent (350) installed on the client or partner. In this case, the information exchanged can be stored in the message box (2110) of the manager system that provides and manages the instance system.

An agent adapter (1350) installed on a worker node of an instance system according to an embodiment may include an agent control unit (1351), a transmission/reception setting unit (1352), and a transmission/reception processing unit (1353).

Meanwhile, an agent (350) installed in a client or partner system may include an agent control processing unit (351), a transmission/reception setting processing unit (353), and a transmission/reception unit (357).

In general, since the agent adapter (1350) is a software package, the agent control unit (1351), the transmission/reception setting unit (1352), and the transmission/reception processing unit (1353) can each be logical components of the software. Similarly, since the agent (350) is also a software package, the agent control processing unit (351), the transmission/reception setting processing unit (353), and the transmission/reception unit (357) can each be logical components of the software.

To transmit and receive data from client or partner systems as transaction data, such as EDI data, clients or partners can install agents to communicate information with internal systems. This example illustrates a situation where the client or partner system includes internal systems such as an SAP ERP system, a database such as an RDBMS, or an IBM system's message queue.

The agent control unit (1351) can control an agent (350) installed in a client or partner system. For example, the agent control unit (1351) can start, terminate, or update an agent (350). In this case, if the agent control unit (1351) does not directly request and control the agent (350) but only updates the request information to control the agent (350), the agent control processing unit (351) of the agent (350) can retrieve the updated request information according to a set cycle and perform agent control according to the request information.

The transmission/reception setting unit (1352) of the agent adapter (1350) can change and set the transmission/reception processing information of the agent (350). In this case, the transmission/reception processing information to be changed can be stored in the transmission/reception setting unit (1352) without being transmitted to the agent (350).

Then, the transmission/reception setting processing unit (353) of the agent (350) can periodically retrieve the transmission/reception processing information changed by the transmission/reception setting unit (1352) of the agent adapter (1350) and save the transmission/reception processing information as a file. The stored transmission/reception processing information is valid only while the agent (350) is running. If the agent (350) is restarted, the agent (350) can retrieve new transmission/reception processing information from the agent adapter (1350) and process it again. Therefore, the agent adapter (1350) can remotely set and control the transmission/reception operation of the agent (350).

The transmission/reception unit (357) of the agent (350) can use the transmission/reception processing information stored as a file to retrieve information from an internal system (here, SAP ERP system, RDBMS database, message queue message queue) and transmit it to the transmission/reception processing unit (1353) of the agent adapter (1350), or change and store information received from the transmission/reception processing unit (1353) of the agent adapter (1350) in the internal system.

Meanwhile, the transmission/reception processing unit (1353) stores the system information transmitted by the transmission/reception unit (357) of the agent (350) in the message box (2110) within the manager system, or causes the transmission/reception unit (357) of the agent (350) to receive various pieces of information set in the agent adapter (1350) and stores the information in the message box (2110).

In this way, a platform according to an instance system can install an agent on a client or partner system and enable the installed agent and the agent adapter of the platform to communicate, thereby stably communicating the system data of the client or partner.

Additionally, agents communicate with agent adapters through authentication, and agent adapters can remotely configure settings for agent data transmission and reception. This minimizes the need for agent adapters to directly configure actions or information on agents, making configuration management safe and easy.

FIG. 20 is a diagram disclosing an embodiment of running an adapter in a workspace according to an embodiment.

To facilitate the development of adapter packages, the present invention provides an easy construction method for various standard link protocols and aims to provide an app store (1510) for exchanging adapter packages among developers.

Here, the app store (1510) may include an adapter package sales unit (1501) and an adapter package purchase unit (1502). The app store (1510) may refer to the above-described embodiment and may represent a platform where developers can upload adapter packages and users can purchase and download adapter packages. This will be described later. In one embodiment, a developer must obtain approval from an administrator to sell an adapter package through the app store (1510).

As described above, the client (here, the client may include both developers and users, 100) can create, execute, and modify various packages in the workspace (1500, 3000). In particular, the client (100) can execute an adapter package in the workspace (1500, 3000). An example of executing an adapter package is as described above.

In one embodiment, a developer can develop an adapter in the application service manager and run the adapter in a workspace (1500, 3000) to test the developed adapter. At this time, the adapter package is installed in the workspace (1500, 3000) as a unit, and the program (program code and related settings) included in the installed adapter package can be run on the workspace (1500, 3000).

In one embodiment, when running an adapter, it may interact with the platform described above to resolve the requirement. That is, the platform depicted in the drawing may be provided through the application service manager described above, and is not a concept included in the workspace (1500, 3000).

The services provided by the platform can support the following functions:

The Message Box service represents a service that retrieves and stores sent and received documents.

Communication Protocol Access Services represent services for accessing external communication protocols. For example, these represent services for HTTP/HTTPS and FTP access.

The configuration repository service represents a service that stores and retrieves the configuration required for the adapter to run.

This has the advantage that platform service providers can expect additional revenue and diffusion effects by providing an app store for buying and selling adapters and a workspace (1500, 3000) for developing and running adapters.

Additionally, users can build various standard linkage protocols through the process of purchasing, installing, configuring, and running the created adapter, and from the perspective of adapter developers, there is an advantage in that they can generate revenue by developing and selling adapters.

Figure 21 is a drawing disclosing an example of an adapter package.

A package is a bundle of programs (code files or configuration files) that are installed and run in a workspace. It includes adapter packages, integration packages, and resource packages. Integration packages and resource packages are described above.

An adapter package represents a package that supports the use of various protocols and platform-specific services for integration. Typically, adapter packages are configured web-based using platform-specific services, and the configured information (channels) can be used in the integration package. This is described above.

In one embodiment, the adapter package may include the following adapters, which allow for addressing a wide variety of requirements through the adapter package described below.

The first adapter package (1520a) may include a protocol adapter. Here, the protocol adapter includes a standard protocol communication adapter such as EDIINT, OFTP, etc.

The second adapter package (1520b) may include a mapping/conversion program adapter. Here, the mapping/conversion program adapter represents an adapter that provides for easy mapping and conversion operations.

The third adapter package (1520c) may include a web scraping adapter. Here, the web scraping adapter represents an adapter for scraping functionality in a web service that is provided only as a web service and not through standard communication.

The fourth adapter package (1520d) may include a development wizard adapter. Here, the development wizard adapter represents an adapter that generates a linked flow (program flow) of specific patterns in a wizard-like manner.

Of course, the adapter package may include other adapters developed by developers through the workspace in addition to the adapters described above.

FIG. 22 is a drawing disclosing an example of an adapter using a framework according to an embodiment.

The Core can provide the following services, corresponding to the framework described above.

(1) Configuration Repository: This can store and manage configuration information. This allows the system to store configuration data and provide access to necessary configuration information.

(2) Distributed Task Service: This service can process and manage tasks in a distributed environment. This allows for task distribution and status tracking across multiple nodes or systems.

(3) Channel Registry: This registry can handle the registration and management of communication channels. Through this, channels can be registered and used for communication between different systems or packages.

(4) Message Box Service: Supports message-based communication. This provides functions such as message transmission, reception, storage, and routing, enabling asynchronous communication between various systems.

(5) File Watch System: A system that processes file changes and monitoring, and can monitor changes in the file system and perform necessary tasks.

The adapter of the present invention can use the API to utilize the framework. That is, the adapter can utilize the core services through the API.

The API can provide the following services:

(1) Configuration Service: A service interface that provides access to configuration settings and can support viewing, modifying, deleting, etc. configuration data.

(2) Task Service: This is a service interface for using functions related to task processing, and can provide task management functions such as task creation, status inquiry, and result return.

(3) Channel Access Service: A service interface that provides access to communication channels, and can provide functions such as channel creation, message transmission, and reception.

(4) Message Box Access Service: A service interface that provides access to the message box and can provide functions such as creating, sending, receiving, and deleting messages.

(5) User Class: A class registered in the registry using the API and can be referenced by web services or other classes.

(6) File Watcher: An interface that handles file monitoring, can handle file change events, and perform necessary tasks.

A user implement can provide the following services:

(1) Web Service: This is the implementation code used by users to develop web-based services, and the settings required for the adapter to run can be provided through a web interface.

(2) User Classes: User-defined classes that developers write to implement their own logic. They can implement specific domain or business logic by utilizing the functions of the Core or API.

(3) File Watcher Implementation: This is the implementation code that handles file monitoring. It can interact with the File Watch System to handle file change events and perform necessary tasks.

FIG. 23 is a drawing disclosing an example of a service provided by an adapter package according to an embodiment.

The Application Context is a component included in the framework and can contain service APIs for developing adapter packages. For example, the service APIs can include WorkspaceIdentity, MessageAccessService, MessageSlotInfoService, ConfigurationService, TaskService, ChannelAccessService, and FileAccessService.

In one embodiment, the developer of an adapter package can specify a method to be executed according to the adapter package's life cycle. The developer can use annotations related to the life cycle. For example, a specific method can be specified to be executed when the package starts or ends. This will be described later.

Additionally, services registered in the Application Context can interact with user classes registered as beans. For example, user implementation classes registered as beans may include FileWatcher, TaskImple, ChannelProcessorImple, and other user-defined classes. These classes implement specific functions or business logic of the application and are registered as beans in the application context so that they can be used by other components. This allows the framework to manage instances of user classes and create and use objects required by the application.

In one embodiment, the Application Context registers a user component as a bean so that it can be referenced in a web service (e.g., Rest, Servlet). In one embodiment, when referencing a user component in a web service, the reference is made directly through the Application Context. The method is as follows.

Method:

- T getInstance(Class<T> type): Returns the services and objects registered in the Application Context.

- WorkspaceIdentity getWorkspaceId(): See WorkspaceIdentity

- String getPackageId(): Returns the package ID value.

At this time, Rest API can be implemented through JAX-RS API. To do this, register REST service with @RestService Annotation and access it with /pkg/{workspace_install_path}/{package_install_path}/rest/{path).

Additionally, the Servlet API can be implemented through the javax.servlet API.

To do this, register a Servlet with @Servlet("Servlet pattern") and access it with pkg/{workspace_install_path}/{package_install_path}/{Servlet pattern}.

The description of WorkspaceIdentity is as follows. WorkspaceIdentity contains information about the workspace to which the adapter package belongs and can generate tickets. WorkspaceIdentity corresponds to a class used for workspace authentication when the adapter package uses the Cloud EDI service. WorkspaceIdentity is required when using the API provided by the Cloud EDI platform. Here's how.

Method:

- getId(): Returns the unique ID of the workspace to which the package belongs.

- getTicket(): Returns a ticket that authenticates the workspace to which the package belongs.

The following describes TaskService. TaskService can provide functionality related to distributed task scheduling. TaskService can register tasks in a distributed environment and schedule them for periodic execution. Tasks registered by the distributed task service can be executed at a specified time or based on an event.

In other words, TaskService can be used in adapter packages to register and cancel specific tasks with the distributed scheduler. Users can implement the Task interface, and the distributed scheduler can support Cron and Secondary methods. The methods are as follows.

Method:

- register(TaskConfig config, Task task): Registers a task with the distributed scheduler.

- return: task unique ID)

- unregister(String taskId): Unregisters a task with a unique ID from the distributed scheduler.

The MessageBoxAccessService is described below. MessageBoxAccessService accesses EDI message boxes to enable document transmission and reception. For example, it can access cloud-based message boxes to transmit data and process received data. Here, MessageBox represents an API that accesses the message box repository to store, retrieve, or delete documents. The method is as follows:

Method:

- send(): Saves a document to a MessageBox.

- queryPendingMessageList(): Returns a list of message records (message headers) in the pending transmission state (TBDL, WAIT) for the given slot/path name.

- receivePayload(): Returns the message body.

- updateMessageStatus(): Changes the message status.

- deleteMessage(): Delete a message

The description of MessageSlotInfoService is as follows. MessageSlotInfoService corresponds to a service that contains slot information for message boxes. The method is as follows.

Method:

- getSlotId(String workspaceId, String pathname): Returns the message slot ID corresponding to the workspace ID and path name.

- getMessageBoxId(String slotId): Returns the message box ID to which the message slot belongs.

- getSlotMap(String workspaceId): Returns a list of message slots accessible in the workspace.

The following describes ConfigurationService. ConfigurationService corresponds to a service that accesses the Config Repository to retrieve, modify, and delete configuration information. This allows for managing configuration data and accessing necessary configuration information. ConfigurationService represents an API that allows a package to directly access the Config Repository, read, modify, or delete its configuration. The method is as follows:

Method:

- list(WorkspaceIdentity, String packageId, String nodePath): A method for providing a web service that retrieves a list of node paths within a requested path for a specific workspace and package, and retrieves the configuration information required for the settings screen UI in Web Admin.

At this time, it is recommended to use FsWatchSystem to apply the setting values in the adapter package.

- create(WorkspaceIdentity, String packageId, ConfigNode node): Creates a configuration node.

- update(WorkspaceIdentity, String packageId, ConfigNode node): Changes the configuration node.

- remove(WorkspaceIdentity, String packageId, ConfigNode node): Deletes a configuration node.

The FileWatchSystem is described below. FileWatchSystem can monitor file changes in a given path or directory and provide functionality to perform necessary actions. More specifically, FileWatchSystem periodically monitors directories in registered paths, detects file creation, modification, and deletion, and can interface with them through registered FsWatcher instances. Here, FsWatcher instances can implement actions to be taken when file changes are detected within the path. For example, the method is as follows:

Method:

- init(Set<File> fset, String path): Executed when FsWatcher is first registered, passing the file set in the path registered as a parameter.

- process(FsEvent): Returns the file where the change was detected and the event type.

The FileAccessService is described below. FileAccessService can be used to access files by accessing an FTP server within Cloud EDI or an external FTP server. The method is as follows:

Method:

- put(String workspaceId, String serviceName, String folderPath, String filename, byte[] body): Transfers a file to the FTP service path with the ServiceNamed registered in the workspace.

- get(String workspaceId, String serviceName, String folderPath, String filename): Receiving a file in the FTP service path with the ServiceNamed registered in the workspace.

- list(String workspaceId, String serviceName, String folderPath, String pattern): Retrieves a list of files in the target path that match a GLOB pattern.

- delete(String workspaceId, String serviceName, String folderPath, String filename): Deletes the file in the target path.

ChannelAccessService is a component that provides distributed channel access services in response to channel requests. A specific process can subscribe to a channel and process messages or events received from it. This allows data to be transmitted through the channel and received and processed. The method is as follows.

Method:

- create(String channelId, String channelName): Pre-create a channel in the workspace.

- subscribe(ChannelProcessor processor): Register an interface to process as the package's default channel.

- Subscribe(String channelId,ChannelProcessor processor): Registers a channel with a specific channel ID.

- unsubscribe(): Unsubscribes the package from the default channel.

- unsubscribe(String channelId): Unsubscribes from a specific channel.

- call(ChannelRequest request): Calls a specific channel.

FIG. 24 is a drawing disclosing an example of an adapter developed in a workspace according to an embodiment.

Through the above-described embodiment, a developer can develop a first adapter package (324) that performs the role of a router. Here, the adapter included in the first adapter package (324) corresponds to a service that facilitates routing through settings.

According to an embodiment, a client (310) can provide an application service, such as the example disclosed, to a desired partner (320). The embodiment can not only provide a service from the client (310), but also enable the client (310) to directly provide a customized service to a desired partner (320) using the embodiment.

This drawing illustrates an embodiment of providing an EDI service using the first adapter package (324) described above. For a client (310) to transact with a partner (320), the embodiment may provide a coordinator (1100) and worker nodes (1300a, 1300b) included in an instance system. Here, the first worker node (1300a) and the second worker node (1300b) correspond to the same or different nodes.

In one embodiment, the adapter package (311) with which the client (310) communicates has a first agent (312) installed, and EDI information, which is information required for a transaction, can be requested through the first agent (312). Here, the EDI information corresponds to the original EDI message (313).

The first agent (312) with which the client (310) communicates transmits the received requested EDI information to the message box service (2110). In one embodiment, the message box service (2110) may be provided by an application service manager.

The message box service (2110) can store EDI information received from the first agent (312) in the client inbox (2111).

Thereafter, the EDI information may be transmitted to the first adapter package (324) running on the first worker node (1300a) within the instance system. Here, the first adapter package (324) may perform the role of a router as described above.

In one embodiment, the first adapter package (324) may store EDI information including the Original EDI Message (313) in the first partner outbox within the message box service (2110) based on information received from the coordinator (1100). In addition, the first adapter package may transmit the EDI information including the Original EDI Message (313) to the integration package (1380) of the second worker node (1300b) based on information received from the coordinator (1100). At this time, the first adapter package may refer to the distributed scheduler of the coordinator (1100) and lookup the adapter channel registry.

The integrated package (1380) can convert EDI information received through the above-described embodiment. At this time, the integrated package (1380) can subscribe to an adapter channel registry. Here, subscription refers to the process of registering (subscribing to) a "distributed channel name" to be called when a specific flow or logic of the integrated package is called from a router package. For example, the router package of node #1 can call the coordinator (1100) by looking up which node the corresponding channel is on.

Accordingly, the second worker node (1300b) including the integrated package (1380) can store EDI information including the Transformed EDI Message (314) in the second partner outbox of the message box service (2110).

Thereafter, the message box service (2110) can transmit EDI information including the Original EDI Message (313) stored in the first partner outbox to the first partner (322) of the adapter package (321) communicating with the partner (320). In addition, the message box service (2110) can transmit EDI information including the Transformed EDI Message (314) stored in the second partner outbox to the second partner (323) of the adapter package (321) communicating with the partner (320). Here, the first partner (322) and the second partner (323) correspond to the trading partners of the customer company. This is because the customer company (client) can exchange documents with multiple partners.

As a result, the partner (320) can receive the EDI information transmitted by the client (310) as standardized EDI conversion data. When the partner (320) transmits its own EDI information to the client (310), the data can be transmitted according to a similar process.

Accordingly, clients (310) and partners (320) can easily use application services such as EDI services according to the disclosed embodiments, and can easily conduct transactions according to the standardized format even if they do not know the standardized format or do not accurately understand the documents and information requested by the transaction counterparty.

Additionally, clients (310) or partners (320) can develop or utilize adapter packages such as the above in their workspaces and link them to the integrated package (1380). The embodiment provides a simple interface for developing such packages and linking them to existing packages, and the developed packages can also be sold, shared, or provided separately.

FIG. 25 is a drawing disclosing an example of an application service providing device converting a data format according to an embodiment.

In the illustrated example, the application service providing device (300) may include an instance system (not shown) and a manager system (not shown). The instance system may include a worker node (e.g., Node #N) on which an agent adapter (1350) and a mapping adapter (1370) are installed, and may provide application services to a client (100) and a partner (200).

The manager system (not shown) may include an application service manager (2100), and the application service manager (2100) may obtain data collected from the agent (350) of the client (100) and the agent (450) of the partner (200) from the agent adapter (1350) installed in the worker node. The mapping adapter (1370) may unmarshall the source document data of the client (100) and output it as target document data mapped with information required by the partner (200).

Accordingly, the application service providing device (300) according to an embodiment of the present invention may include an agent adapter (1350), a mapping adapter (1370), and an application service manager (2100).

The agent adapter (1350) may include a transceiver (810). The transceiver (810) may receive source document data from the agent (350) of the client (100). For example, the source document data may be expressed as text data. In one embodiment, the source document data received from the agent (350) may be stored in a message box (2110) included in the application service manager (2100).

The mapping adapter (1370) may include a deserialization unit (820), a mapping unit (830), and a serialization unit (840). In this case, the deserialization unit (820) may convert source document data having a first data format into source structure data based on a pre-stored source schema. The mapping unit (830) may convert source structure data into target structure data based on at least one of a pre-stored source schema, a pre-stored mapping script, or a pre-stored target schema. The serialization unit (840) may convert target structure data into target document data having a second data format based on a pre-stored target schema. In one embodiment, the converted target document data may be stored in a message box (2110).

In one embodiment, at least one of the source schema, the mapping script, or the target schema may be generated based on user input of the client (100) or partner (200) to a graphical user interface (GUI) of the platform of the instance system (1000) provided to the client (100) or partner (200), and may be received via the agent adapter (1350) and pre-stored in the message box (2110).

The agent adapter (1350) can receive target document data having a second data format converted from source document data having a first data format from a message box (2110) and transmit it to the agent (450) of the partner (200).

FIG. 26 is a diagram showing an example of an application service providing device according to an embodiment converting a data format using a schema and a mapping script.

The deserialization unit (820) can convert source document data having a first data format into source structure data based on a pre-stored source schema. In one embodiment, the first data format may include at least one of the first data format or the first data structure.

The deserialization unit (820) can convert source document data (e.g., text) into source structure data (i.e., internal structure) in the opposite direction of serialization. In other words, the deserialization unit (820) can parse source structure data from source document data.

That is, the deserialization unit (820) can perform deserialization (parsing) to create an internal data structure that can map the source document data (i.e., original data) based on the structure information and annotation information of the source schema for the source document data.

The mapping unit (830) may convert source structure data into target structure data based on at least one of a pre-stored source schema, a pre-stored mapping script, or a pre-stored target schema. In one embodiment, the mapping script may include at least one of statement information representing the grammar of a programming language or expression information representing a specific result value.

In one embodiment, the mapping unit (830) may perform mapping to convert source structure data into target structure data using structure information including the structure (tree) and name (Identifier) of the source document data.

In one embodiment, at least one of a source schema, a mapping script, or a target schema may be included and stored in a mapping program. The mapping unit (830) may convert source structure data into target structure data based on the mapping program. In this case, the annotation information of the source schema and the target schema is used only for serialization and deserialization, and is not used in the mapping program. This is because the mapping based on the mapping script is intended to focus only on mapping data between schema nodes of the source schema and the target schema.

That is, according to the present invention, by intentionally separating the roles of the mapping script and the annotation information of the schema (SoC - Separation of Concerns), the mapping script is used only for mapping regardless of serialization and deserialization, and the annotation information of the schema is used only for serialization and deserialization, thereby effectively supporting domain-specific language (DSL)-based mapping.

Additionally, according to the present invention, serialization and deserialization are performed to convert a data format (i.e., at least one of a data format or a data structure), and mapping can be performed to convert source structure data into target structure data regardless of the conversion of the data format.

The serialization unit (840) can convert target structure data into target document data having a second data format based on a pre-stored target schema. In one embodiment, the second data format may include at least one of the second data format or the second data structure. That is, for example, the target document data may have a different data format from the source document data. Furthermore, for another example, the target document data may have the same data format as the source document data but a different data structure.

Specifically, the serialization unit (840) can perform serialization to convert target structure data into target document data (e.g., text) having a second data format based on the structure information and annotation information of the pre-stored target schema.

For example, the serialization unit (840) can convert target structure data contained in an internal program language variable into target document data such as EDI, XML, or JSON.

Therefore, according to the present invention, a domain specific language (DSL) can be used to define a schema for serializing/deserializing documents of various data formats by utilizing annotation information.

In addition, according to the present invention, a self-mapping script language capable of solving various mapping requirements with a relatively simple programming language grammar can be provided.

In addition, according to the present invention, a unified schema definition grammar can be provided for documents of various data formats.

In addition, according to the present invention, it is possible to provide a function that can create simple to complex mappings through a relatively simple mapping script language and Lua custom function functions.

In addition, according to the present invention, by providing these functions as DSL, it is possible to easily develop functions.

Figure 27 is a diagram disclosing an example of deserialization and serialization based on a schema according to an embodiment.

In one embodiment, deserialization, which converts document data into structured data, may be performed based on a schema for the document data. For example, the document data may include various types of document data, such as EDI documents, XML documents, and JSON documents. In this case, deserialization may be referred to as unmarshaling or a term with an equivalent technical meaning. In one embodiment, the document data for deserialization may include source document data, and the structured data may include source structured data.

In one embodiment, serialization, which converts structured data into document data, may be performed based on a schema for the document data. In this case, serialization may be referred to as marshaling or a term with an equivalent technical meaning. In one embodiment, the structured data for serialization may include target structured data, and the document data may include target document data.

In one embodiment, a schema may include at least one of structural information or annotation information regarding document data. The structural information represents the structure of the document data and may include data defined by a data type. For example, the data type may include at least one of Primitive, Record, Array, or TypeRef.

Primitives can specify primitive types such as string, int, long, double, and decimal. For example, String represents a string data type, and Int represents an integer data type. Record can have other subtypes and can be composed of a collection of data of different types. Array can be defined as an array of specific types and can be composed of a collection of data of the same type. TypeRef can be retrieved by referencing an already defined Record.

In one embodiment, the annotation information may correspond to a data type and include information used when recognizing (parsing, deserializing) the data from the document data. For example, @XmlElement(name="" may represent an annotation, and the XmlElement described after @ may represent the name of the annotation and include an element named name, the value of which may be "employee".

Also, for example, if the @JsonProperty(name="" annotation information is included in the schema, employee-id instead of id may be displayed in the box display of the JSON document according to the annotation information during marshaling. On the other hand, if the @JsonProperty(name="" annotation information is not included in the schema, id may be written in the box display of the JSON document according to the int id; structural information of the schema during marshaling. In one embodiment, such a schema may be defined as Backus-Naur Form (BNF), which is a grammar expression that can define the syntax of a programming language.

Figure 28 is a drawing disclosing an example of a mapping script according to an embodiment.

A mapping script may be used to transform source structure data into target structure data in the form of a target schema. In one embodiment, the mapping script may include at least one of sentence information representing the grammar of a programming language or expression information representing a specific result value.

Here, sentence information can represent each line of the programming language of the mapping script. That is, the mapping script can be composed of sentence information. In one embodiment, the sentence information can represent a correspondence between the structural information of the source schema and the structural information of the target schema.

For example, sentence information may include MapStmt, LoopStmt, IfStmt, MatchStmt, LoopVarSetStmt, and LoopVarIncStmt, but is not limited thereto and may include various sentence information. In this case, MapStmt may include sentence information that performs mapping. LoopStmt may include sentence information that represents a loop statement and may perform a function similar to a for statement in a general programming language. IfStmt may include sentence information that represents a conditional statement and may perform a function similar to an if statement in a general programming language. MatchStmt may include sentence information that represents a conditional control statement and may perform a function similar to a switch statement in a general programming language. LoopVarSetStmt may declare a variable to be used within the Loop. LoopVarIncStmt may include sentence information that increments a specific variable (e.g., LoopVar).

Additionally, expression information can specify where to get the value to use, and can represent an expression that is converted to a single value through evaluation. For example, expression information can include, but is not limited to, Constant, Path, Custom Function, and LoopVar, and can include various expression information. In this case, Constant can be represented by directly specifying a string or number. Path can represent a specific path of the source. Custom Function can represent a function created by the user. LoopVar represents a variable of a Loop iteration statement, and can represent a LoopVar such as #i, for example.

In one embodiment, a mapping script may be included in a mapping program. In one embodiment, such a mapping script may be defined in BNF, which is a grammar expression that can define the syntax of a programming language.

Below, an embodiment is disclosed in which a client or partner can develop a required application based on an application package downloaded from a workspace.

Clients or partners can access their own workspace on the platform of the instance system and develop applications necessary for various tasks or transactions based on the graphical user interface (GUI) provided by the platform.

For example, if a client develops an application that delivers EDI information as a service, the client can develop a mapping program that maps standardized transaction information with its partners and provide information to them based on this program. Alternatively, the client can sell the developed mapping program itself on the Manager System platform.

While this example illustrates a mapping program, clients or partners may require different information or document mappings depending on the type of business they operate, the nature of their transactions, etc. Here, mapping refers to the process of converting data (source) with schema A into data (target) with schema B. The schema represents the data structure, with nodes with different names forming a hierarchical structure.

Because these types of businesses are so diverse, the examples herein disclose examples that make it very easy for users to develop mapping programs that can map EDI information.

The platform according to the embodiment can provide an environment and interface for developing a mapping program, which are disclosed in detail as follows.

FIG. 29 is a drawing showing an example of providing a user interface for developing a mapping flow among the disclosed embodiments.

The user interface for developing the mapping flow of the present invention may include a development tool palette (901) and a development GUI code area (902).

Here, the development tool palette (901) may include graphic blocks corresponding to the structure and functions of the language used in the mapping program. That is, the development tool palette (901) may include a list of all keywords used in the mapping program. For example, the development tool palette (901) may include graphic blocks corresponding to control structures and functions such as “Statements”, “MAP”, “If”, “Then”, “Loop for”, “LoopVar”, “LoopVar ++”, and “Match” used in the mapping program. However, the functions included in this drawing are only examples, and it is obvious that other functions may be included.

In one embodiment, the method for providing an application service may provide a user interface including a development tool palette (901) and a development GUI code area (902). Within the user interface, a user may select a graphic block included in the development tool palette (901) and then drag and drop it into the development GUI code area (902).

For example, if the user interface receives an input signal (903a) from the user to select a graphic block of a first function (e.g., a “Statements” block) and then drag and drop it into the development GUI code area, the graphic block of the first function can be output from the development GUI code area (902). In this case, the drag and drop input signal is only an example and may include other preset input signals received from the user.

Here, the “Statements” block must be the top-level block of the mapping program, as it sequentially contains other blocks. In other words, the “Statements” block corresponds to the block containing the beginning and end of the mapping program.

Thereafter, when the user interface receives an input signal (903b) for selecting a graphic block of a second function (e.g., a “LoopVar” block) from the user and then dragging and dropping it into the development GUI code area (902), the graphic block of the second function can be output from the development GUI code area (902). At this time, the development GUI code area (902) can be configured to automatically include the second function within the first function.

In addition, the development GUI code area can output the input fields of the parameters included in the graphic block of the second function as they are. Referring to the “LoopVar” block described above, the “LoopVar” block in the development tool palette is a block that declares the loop variable to be used in the “Loop for” block, and the “variable name” and “initial value” must be specified. Accordingly, since the parameter input fields of the “LoopVar” block are two (variable name, initial value), the parameter input fields can be output as they are while outputting the “LoopVar” block in the development GUI code area as well.

Afterwards, the user can directly enter parameters into the input fields of the "LoopVar" block. For example, the user can enter the variable name "k" and the initial value "1" in the "LoopVar" block. Accordingly, the development code can declare a loop variable called "k" in the loop and assign it an initial value of 1.

Thereafter, when the user interface receives an input signal (not shown) from the user to select a graphic block of a third function (e.g., a “Loop for” block) and then drag and drop it into the development GUI code area (902), the graphic block of the third function can be output from the development GUI code area (902). At this time, the development GUI code area (902) can be configured to automatically include the third function within the first function, following the second function.

In this way, the user interface for developing the mapping flow of the present invention can provide visual assistance to the user in forming a code structure in the development GUI code area (902) using graphic blocks included in the development tool palette (901). This has the advantage of allowing the user to define a mapping program relatively easily even if he or she is not familiar with development scripts.

FIG. 30 is a drawing showing an example of providing a user interface for developing a mapping flow among the disclosed embodiments.

The user interface for developing the mapping flow of the present invention can provide development source code (905) corresponding to the development GUI code area (902).

More specifically, the application service providing method can output source codes corresponding to functions output in the development GUI code area (902) on the development source code area (904). That is, referring to the above-described embodiment, when a user selects a graphic block included in the development tool palette to output a function in the development GUI code area (902) and inputs a parameter corresponding to the function, the application service providing method can generate and output source code (905) corresponding to the function and parameter on the development source code area (904).

In one embodiment, if a user directly modifies the source code (905), the user interface for developing a mapping flow can reflect the source code in real time and output a graphic block corresponding to the modified source code (905) in the development GUI code area (902).

Through this, developers can visually configure a mapping program through the development tool palette and development GUI code area (902) and convert it into source code (905) for verification.

However, developers who are not familiar with programming can easily access the user interface of the present invention, but developers who are familiar with programming may be more familiar with the source code method that compresses the program and may be more productive in the flow of a mapping program in which a large amount of mapping is repeatedly performed.

That is, through the present invention, developers can selectively use the method of directly modifying the development source code area (904) in the source code manner or dragging and dropping the graphic blocks in the development GUI code area (902) according to their personal preferences.

These GUI-based, easy-to-use mapping program definition tools enable developers to easily implement and manage complex mapping logic through a user-friendly interface and visual programming approach.

FIG. 31 is a drawing showing an example of providing a user interface for developing a mapping flow among the disclosed embodiments.

In one embodiment, the application service provision method may utilize a GUI-based library to provide a user interface (UI) for developing mapping flows. In this case, Google's Blockly library may be utilized as a GUI tool for developing or editing mapping flows, but is not limited thereto.

More specifically, the user interface for developing a mapping flow may include a mapping program editing screen and a function editing screen.

This drawing illustrates a mapping program editing screen. In one embodiment, the mapping program editing screen may include a mapping program area (906), a source schema area (907), a target schema area (908), and a mapping expression area (909).

Here, the mapping program area (906) may include the development tool palette and development GUI code area described above. That is, in the mapping program area (906), the user can arrange the necessary blocks (statements) in flow order to perform conversion between a complex source schema and a target schema.

In one embodiment, the mapping program area (906) may include an icon (910) for outputting a source code area. When a user selects the icon (910), the user interface may output a source code area pop-up window for outputting source code corresponding to the development GUI code included in the mapping program area (906). Here, the source code area pop-up window may include the development source code area described above.

Additionally, in one embodiment, a user may select a MAP block from among the development GUI codes being output within the mapping program area (906). Accordingly, the user interface may output the source schema and target schema corresponding to the MAP block to the source schema area (907) and target schema area (908), respectively.

More specifically, the source schema area (907) represents information about the data schema before conversion. In one embodiment, a user can add or delete information about the source schema.

The target schema area (908) represents information about the data schema after conversion.

The source schema area (907) and the target schema area facilitate connections between source schema and target schema nodes.

Additionally, in one embodiment, the user interface may output a mapping line between nodes contained in the source schema and nodes contained in the target schema. This allows the user to visually determine whether a node in the source schema is mapped to a node in a target schema.

Additionally, in another embodiment, when the user interface receives an input signal for selecting a node included in the source schema and then dragging and dropping it to a node included in the target schema, the user interface can automatically output the corresponding mapping formula to the mapping expression area (909).

The mapping expression area (909) is an area that performs mappings between actual nodes. It is displayed when a mapping block is selected from the preceding blocks (Statements), allowing multiple mapping expressions to be inserted between each node. In other words, it corresponds to an area that sets detailed values of the mapping expression. This will be described later.

FIG. 32 is a drawing showing an example of providing a user interface for developing a mapping flow among the disclosed embodiments.

The mapping expression area (909) corresponds to an area that performs mapping between actual nodes. In one embodiment, when a user selects a map block among the blocks included in the mapping program area (906), the user interface may provide a GUI block that allows the user to input a path, data type (e.g., String), function, and input value (Arguments) included in the mapping block on the mapping expression area (909).

Accordingly, the user can select a function block and choose one of the various functions used in the mapping block. The various functions used in the mapping block are described below.

FIG. 33 is a drawing showing an example of providing a user interface for developing a mapping flow among the disclosed embodiments.

In one embodiment, a user interface for developing a mapping flow may provide a schema editing screen. Here, the schema editing screen may include a schema editing area (911) and an annotation area (912).

As described above, the schema editing area (911) is an area where the user edits the schema used in the mapping flow, and an example is shown in this drawing. Here, the schema editing area (911) represents the structure of data and can represent a hierarchical structure of nodes with names. Here, each node can have a type such as Int or String. For example, the user can create a sample node in the mapping program area and set the data type or structure for each node. For example, “String” represents a string data type, and “Int” represents an integer data type.

The annotation area (912) corresponds to an area for editing information required when the data is expressed as text (serialization) in addition to the hierarchical structure of the data. In addition, the annotation area (912) corresponds to an area for editing information required additionally when recognizing (parsing, deserializing) the data from text in addition to the hierarchical structure of the data. Accordingly, the annotation area (912) may include an annotation list (913). Here, the annotation list (913) may include an annotation name and a document type.

At this time, multiple comments can be added per node, and multiple comments with the same name cannot be added. Each comment can have several types depending on the document type (XML, JSON), and each comment can have unique properties (arguments).

For example, “ZmlAttribute” can indicate that when the node is serialized or deserialized to XML, it is an Attribute rather than an XML element.

In addition, the annotation area (912) may further include a user annotation list (914). Here, the user annotation list (914) may further add name and namespace as unique attributes (arguments) corresponding to existing annotations, but they are not mandatory values. That is, both name and namespace may be optionally added. Here, the name may be used to describe the role or meaning of the corresponding argument, and the namespace may be expressed in the form of a URI (Uniform Resource Identifier) to identify a logical group to which the attribute belongs. For example, in the above-described example, in “XMLAttribute”, the name may be specified as an additional attribute when the XML Attribute name is different from the node name, and the namespace may be specified when the XML Attribute belongs to a specific XML namespace.

These are later used in interactions with XML or JSON and can indicate which members should be handled in which way during the process of serializing or deserializing data.

FIG. 34 is a drawing showing an example of providing a user interface for developing a mapping flow among the disclosed embodiments.

As described above, users can customize the functions included in the mapping block. When mapping programs attempt to map data from a source schema to a target schema, they can create the necessary functions and use them within the mapping expression area.

In one embodiment, a function editing screen provided by a user interface for developing a mapping flow may include a function list area (915) and an editing area (916).

The function list area (915) represents an area where users can customize functions. For example, users can create functions and set the number of parameters for the function. For example, the "concat" function concatenates strings, so it is a function that combines given strings to create a new string. Accordingly, the "" function can receive two strings as parameters.

The + button included in the function editing screen allows users to add functions to the function list. Additionally, the edit button allows users to edit functions displayed in the function list area, and the delete button allows users to delete functions displayed in the function list area (915).

The editing area (916) corresponds to an area for editing information about a function selected in the function list area (915).

Here, each function performs its own specific task and can be utilized effectively in programming or data processing tasks. Users can create functions with different implementation methods and syntax depending on the actual language or context in use.

FIG. 35 is a drawing disclosing an example of an application service providing device according to an embodiment creating and testing an integrated package.

In the illustrated example, the application service providing device may include a manager system (2000). In this case, the manager system (2000) may include an application service manager (2100) and a database (2200).

The application service manager (2100) provides a user interface including a development tool for an integration flow for an integration package to the client (310), and allows the user of the client (310) to create an integration package through a drag & drop type GUI (graphical user interface)-based development tool.

In one embodiment, the application service manager (2100) may include a user interface processing unit (921), an integrated package generation unit (922), an integrated package testing unit (923), and an integrated package providing unit (924).

The user interface processing unit (921) may provide a user interface including a development tool for an integration flow for an integrated package to the client (310). In one embodiment, information about the integration flow of the integrated package may be stored in an editable form in a database (2200).

In one embodiment, upon receiving an input signal for the development tool of the integrated flow from the client (310), the integrated package generation unit (922) can generate an integrated package corresponding to the input signal.

In one embodiment, an integrated package can be created based on an input signal from a user of the client (310) within the user interface by selecting a graphic block corresponding to a development tool and dragging and dropping it into the development GUI code area.

That is, according to the present invention, the integrated flow for an integrated package can be intuitively defined through a drag-and-drop method, and a form for entering the necessary parameters for each graphic block can be provided, enabling easy creation of an integrated package. The integrated package testing unit (923) can distribute the integrated package to the development workspace (3000) and perform integrated package testing and debugging.

The integrated package provider (924) can distribute the integrated package to the workspace of the client (310). That is, the integrated package can be distributed and executed in the workspace of each client (310) for actual integration, and the client (310) can periodically perform desired integration tasks through the integrated package.

In one embodiment, the application service providing device may further include an instance system (not shown). In this case, information about the integrated flow may be packaged into an integrated package and installed and executed on the instance system prior to execution or testing of the integrated package.

Thereafter, when the integrated package is executed, the integrated package can exchange information with the message box of the application service manager (2100), the agent adapter of the instance system, and the channel service of the coordinator to implement various requirements that the client (310) and the partner can transact with.

FIG. 36 is a drawing disclosing an example of providing a user interface for developing an integrated flow according to an embodiment.

In one embodiment, a user interface for developing an integrated flow of the present invention may include a development tool palette and a development GUI code area.

Here, the development tool palette can include graphic blocks corresponding to the structure and functions of the language used in the integration package. That is, the development tool palette can include the entire list of keywords used in the integration package. For example, the development tool palette can include graphic blocks corresponding to the control structures and functions for each of the functions included in the integration package, such as connectors, services, processors, control flows, and modifiers, but is not limited thereto, and various functions can be implemented as graphic blocks. For example, a connector can include a “from” block (i.e., From Connector) that indicates the start of a route for the integration flow, and a “to” block (i.e., To Connector) that indicates an operation to the outside, such as calling a service, adapter, etc., or storing data. When an integration flow developed in a development environment is implemented, it can include.

In one embodiment, a From Connector corresponding to a consumer may include at least one of a direct that registers a route within an integrated package and directly calls between routes, a timer that is used when a router runs according to a set cycle and periodically receives and performs source data from the outside, a channel that registers a channel and starts routing when a specific channel is called, a message box that periodically fetches a message in a waiting state for processing and executes a route, or an FTP that checks whether a document exists in a registered FTP service path and starts a route if a document exists.

In one embodiment, if the message contains information such as sender, receiver, message type, etc. and needs to be parsed, the From Connector's message box can be used to add an update field before the route is terminated so that the field values of the message can be changed.

In one embodiment, a To Connector corresponding to a producer may include at least one of a direct that calls another route within the same integration package, a channel that calls a specific channel, a message box that stores the contents of an exchange body, a channel that calls another channel within the workspace, or an FTP that transfers a document to a registered FTP service.

In one embodiment, the To Connector's message box may include a user field feature. In this case, desired information within the integration flow may be stored in the user field, allowing for retrieval. In one embodiment, the user field may be added to the exchange header before storing the document in the message box. For example, when receiving a document from an agent, the user field may be added because the agent channel is identified by a user field (e.g., channelId).

When documents are saved to message boxes in an integrated flow, searches can be performed based on additional information such as control numbers.

A service can provide access to the integrated flow, or it can provide a current ControlNumber or memory cache service. A processor can define the processing of messages within the integrated flow. A control flow can provide looping and branching capabilities within the integrated flow. A modifier can provide functions such as getting and setting exchange values.

However, the functions included in this drawing are only examples and other functions may be included.

In one embodiment, the method for providing an application service may provide a user interface including a development tool palette and a development GUI code area. Within the user interface, a user may select a graphic block included in the development tool palette and then drag and drop it into the development GUI code area.

For example, if the application service providing device receives an input signal from the client (310) via the user interface to select a graphic block of the first function (e.g., a “from” block) and then drag and drop it into the development GUI code area, the graphic block of the first function can be output from the development GUI code area. At this time, the drag and drop input signal is only an example and may include other preset input signals received from the client (310).

Here, the "from" block must be the top-level block of the integrated flow, which sequentially includes other blocks. In other words, the "from" block corresponds to the block containing the start and end of the integrated flow.

Thereafter, when the user interface receives an input signal from the user to select a graphic block of a second function (e.g., a “switch” block) and drag and drop it into the development GUI code area, the graphic block of the second function can be output from the development GUI code area. At this time, the development GUI code area can be configured to automatically include the second function within the first function.

Thereafter, when the user interface receives an input signal from the user to select a graphic block of a third function (e.g., a “case” block) and drag and drop it into the development GUI code area, the graphic block of the third function can be output from the development GUI code area. At this time, the development GUI code area can be configured to automatically include the third function within the second function.

In addition, the development GUI code area can output the input fields of the parameters included in the graphic blocks of each function as they are. Referring to the "from" block described above, the "from" block in the development tool palette defines the start of a route and must specify an object for retrieving data. Accordingly, the development GUI code area can also output the "from" block while outputting the input fields of the parameters as they are.

Afterwards, the user can directly input parameters into the input fields of the "from" block's parameters. For example, the user can input the variable name "MessageBox:AA_IN" into the "from" block. That is, the application service provider can receive input signals for the parameters of the graphic block output in the development GUI code area through the user interface. Accordingly, the development code can retrieve data from the MessageBox AA_IN.

As such, the user interface for developing the integrated package of the present invention can provide visual assistance to users in structuring code in the development GUI code area using graphic blocks included in the development tool palette. This has the advantage of allowing users, even those unfamiliar with development scripts, to define the integrated flow with relative ease.

In addition, according to the present invention, the items of the developed integrated flow can be distributed after packaging and converted into a program based on an open source framework at the time of execution by a pre-stored interpreter at runtime, thereby generating an integrated package in an executable form.

FIG. 37 is a drawing disclosing an example of providing a user interface for developing an integrated flow that performs mapping according to an embodiment.

An embodiment of the present invention will now be described in detail with respect to developing an integrated flow for performing mapping based on a stored mapping program. Specifically, the drawing illustrates a user interface for setting information regarding the "toBlock" element among the route input/output (From connect/To connector) coding elements.

That is, a user of the client (310) can develop an integrated flow using a connector by using the user interface of the present invention, and at this time, can set a variable parameter for “”.

For example, a user can set a mapping file (mappingFile) of “toBlock” and set the source type (sourceType) and target type (targetType).

This diagram illustrates the process by which a channel called ame/AME_ADAPTER calls an adapter that performs mapping.

mappingFile represents a mapping program file saved through the above-described embodiment, sourceType represents the type of source document data (e.g., EDI, XML, JSON), and targetType represents the type of target document data.

In one embodiment, when mapping is actually performed, data (body data) in the integration flow is converted from a source type to a target type. That is, if the source document data type is EDI, the target document data type can be converted to JSON through the mapping program.

Web EDI service allows customers who do not have an EDI system to use a web system to automate tasks such as ordering, receiving, billing, and delivery information between companies through EDI services with their partners.

In other words, while web EDI service systems play a crucial role in supply chain management, difficulties can arise if they fail to integrate the diverse systems of multiple manufacturers. Specifically, because traditional EDI systems are optimized for specific large manufacturers, suppliers supplying multiple manufacturers face the burden of manually adapting documents to each different system.

To this end, the present invention seeks to solve this problem by providing a web EDI service.

FIG. 38 is a drawing disclosing an example of providing a web EDI service using a message box according to an embodiment.

According to an embodiment, a web EDI service user (157) can utilize a web EDI service (156). The web EDI service of the present invention can be provided in connection with the message box (2110) of the application service manager described above.

In one embodiment, a Web EDI service user (157) can upload an Excel file or the like to a draft document on the Web EDI service (156). The uploaded Excel file or the like can be sent to a specific message box (2110) and transmitted to the other party after going through a verification and conversion process. Here, the other party may be a partner system of the Web EDI service user.

Additionally, the web EDI service (156) of the present invention can support an EDI viewer, editor, and EDI form designer for each document type. Accordingly, corporate users can develop EDI form templates through the EDI viewer and editor, and developers can develop EDI form templates through the EDI form designer. In this case, the web EDI service (156) of the present invention can provide basic templates for standards such as Forecast, ASN, and Invoice.

Furthermore, the web EDI service (156) of the present invention can effectively manage customer-specific product codes by mapping customer-specific buyer item codes and seller item codes, thereby simplifying order processing and tracking. Furthermore, by managing customer-specific master codes (customer-specific carrier codes, packaging types, etc.), data related to the transportation and packaging of products within the supply chain can be maintained consistently. Master codes can be referenced in viewers and editors and managed through a separate management screen, as will be described later.

Below, the individual features of the web EDI service (156) provided by the present invention will be examined in detail.

This can provide a number of benefits, including time savings and error reduction, efficient supply chain management, cost savings, stronger relationships with customers and partners, and enhanced compliance and security.

FIG. 39 is a drawing disclosing an example of providing a web EDI service using a message box according to an embodiment.

This drawing shows an embodiment of providing a web EDI service (156) to a web EDI user (157). To this end, the present invention can map an EDI document (e.g., X.12 or EDIFACT) of a message box (2110) through a mapping program schema to output an XML (TXT file) document, which can then be output on the web EDI service (156).

More specifically, the web EDI service (156) can convert an EDI document into an Excel file by converting it into an XML document and then going through a rendering process using a rendering script (groovy), rather than directly converting it into an Excel file.

In particular, since directly inputting an EDI document as input data into the rendering script used in the rendering process (the description of groovy is as described above) makes the document structure and programming difficult, the rendering script uses an XML document as input data. To this end, the EDI document in the message box (2110) can be output as an XML document and then used as input data for the rendering process.

In one embodiment, the Web EDI service (156) can output the XML document (TXT file) as pre-conversion data in a pop-up format if the rendering process fails. This allows the Web EDI user (157) to track where and how the conversion went wrong through the XML document (TXT file). This will be described in detail later.

Afterwards, the web EDI service (156) allows the web EDI user (157) to view or download the Excel file, which is the output data of the rendering process. At this time, it is of course possible to apply the Excel file to files with other extensions, such as PDF files or HTML (web) files.

FIG. 40 is a drawing illustrating an example of an interface of a platform according to an embodiment.

As described above, the application service providing device/method of the present invention can provide various application services.

At this time, when a client connects to a system that is initiated, the platform may provide at least one user interface menu.

For example, a first user interface menu may include user interface menus related to a user-specific workspace (e.g., options for a user-specific workspace, a message box, file transfer history with partners, messages sent to mobile devices (SMS), and information about standard mappings if the information exchange involves EDI).

As another example, the second user interface menu may correspond to the Web EDI service (156) menu. Accordingly, a Web EDI user can access (log in) the system disclosed in the present invention and utilize the Web EDI service (156).

FIG. 41 is a diagram illustrating an example of a user interface of a web EDI service according to an embodiment.

When a client connects to a system initiated by the client, the platform may provide a user interface menu for the Web EDI service (156).

For example, the platform may provide options for the Inbox document service (158), the Draft document service (159), and the Sent document service (160) menus.

The Inbox Document Service (158) is a service for clients connected to the platform to view received documents, the Draft Document Service (159) is a service for uploading documents and performing conversion tests (e.g., from an Excel file to an XML file) before transmission, and then actually performing a transmission request, and the Sent Document Service (160) is a service for viewing transmitted documents. Clients can check both the Excel file before conversion and the original XML file (in TXT format) after conversion through the Inbox Document Service (158), the Draft Document Service (159), and the Sent Document Service (160) via the platform. This will be described in detail later.

In addition, the platform may provide a user information management menu (163) for users accessing the web EDI service (156). The user information management menu (163) may provide user information. Here, the user information may include personal information such as a user ID, customer ID, user name, mobile phone number, email address, job title, job responsibilities, and time zone. In addition, the client may change personal information or the login password for accessing the web EDI service (156) through the user information management menu (163).

FIG. 42 is a diagram illustrating an example of a user interface of an inbox document service according to an embodiment.

This drawing illustrates an embodiment in which the platform provides a user interface for an inbox document service (158) when a client selects an inbox document service (158) menu provided by the platform.

More specifically, the inbox document service (158) can output information about the document received by the client. In one embodiment, the information about the received document can include the create time, message type, trading partner, status, and view/download menu. Here, the message type can indicate the number of the standard document. For example, the ANSI X.12 standard uses a three-digit number, and EDIFACT can use a six-digit character. Details about this are disclosed in the standard document. In addition, the status of the received document provided by the inbox document service (158) can be indicated as a status delivered to the recipient (Delivered, after conversion) or a status before being delivered (To be delivered, before conversion).

In addition, the inbox document service (158) can provide a view or download option for the received document. At this time, the view or download option for the received document can be provided as a TXT file, an HTML file, an XLS file, a PDF file, etc., and in particular, the inbox document service (158) is characterized in that in the case of a TXT file, the original document is provided in a pop-up form, in the case of an HTML file, the HTML rendering pop-up form is provided, in the case of an XLS file, the Excel file is provided in a download form, and in the case of a PDF file, the PDF file is provided in a download form. However, it goes without saying that all of the TXT file, HTML file, XLS file, and PDF file can provide a view function in a pop-up form and a download function as a file. Accordingly, the client can view or download the original document or the document after the conversion that performed the rendering process through the inbox document service (158).

Additionally, the inbox document service (158) can search for received documents by filtering them based on at least one of creation time, trading partner, status, message type, and message ID.

FIG. 43 is a diagram illustrating another example of a user interface of an inbox document service according to an embodiment.

This drawing illustrates a pop-up window (164) displayed when a client selects, for example, the view menu for an HTML file from among the menus provided by the inbox document service (158) provided by the platform. The inbox document service (158) can provide a preview window for a document received on a web screen as a pop-up. Here, an HTML file has been described as an example, but it is of course possible for a TXT file to also be provided through the pop-up window (164).

In another embodiment, if an error occurs during the rendering process of an HTML file, an error log may be output instead of a pop-up window. This allows the client to not only check the data before conversion, even if an error occurs during the rendering process, but also track where and how the conversion went wrong. This will be described in more detail later.

FIG. 44 is a diagram illustrating an example of a user interface of a draft document service according to an embodiment.

This drawing illustrates an embodiment in which the platform provides a user interface for a draft document service (159) when a client selects a draft document service (159) menu provided by the platform.

More specifically, through the draft document service (159), a client can upload a document, convert it, and then actually perform a transmission request.

In one embodiment, the draft document service (159) may provide new draft document information through the creation menu (165). The draft document information may include a draft ID, a creation time, a message type, a title, a file name, a status, a message ID, and an action menu. Here, the status of the draft document provided by the draft document service (159) may be indicated as a created status (Created), an uploaded status (Uploaded), a verified status (Verified), and a sent status (Sent).

Additionally, the draft document service (159) can search for a generated draft document by filtering it based on at least one of the creation time, file name, title, status, message type, and draft ID.

In one embodiment, the draft document service (159) may provide various action menus based on each status. In one embodiment, the draft document service (159) may provide a document upload menu (166) when a draft document has been created. The client may upload a document to the web EDI service through the document upload menu (166). In this case, the client may directly upload an Excel file on the web screen.

In one embodiment, the draft document service (159) may provide a document verification and conversion menu (167) when a document is uploaded to the draft document. The client may verify and convert the uploaded document through the verification and conversion menu (167).

In one embodiment, the draft document service (159) may provide a document transmission menu (168) when a document uploaded to the draft document has been verified and converted. The client may transmit the verified and converted document through the document transmission menu (168). In other words, a web EDI user may transmit an uploaded document through the web EDI service. At this time, the web EDI service may send the document requested for transmission to a specific message box and, after going through a conversion process and a transmission process, transmit it to the web EDI user's partner system. At this time, the web EDI user's partner system may correspond to an ERP system, for example.

If a document is sent, the sent message ID may be printed, and the draft document service (159) may provide an original document download menu (169).

Below, we will look at the specific functions provided by the draft document service (159).

FIG. 45 is a diagram illustrating an example of a user interface of a draft document service according to an embodiment.

This drawing shows the user interface provided by the platform when the client selects the creation menu of the draft document service (159) provided by the platform.

When a client selects the "Create Draft Document" menu, the draft document service (159) may provide a message type, title, example template (170), an immediate verification option (178), and an upload file attachment option (179). When the client selects the example template (170), the draft document service (159) may provide a download option for an example Excel template file. Accordingly, the client may create an Excel template file downloaded as an example and then upload the Excel file using the "Upload File Attachment" option (179).

In one embodiment, the draft document service (159) can upload a file, and if the client selects the immediate verification option (178), a verification and conversion process (180) of the uploaded file can be performed automatically as the draft document is generated.

In another embodiment, if the client does not select the "Verify Immediately" option (178), the draft document service (159) may generate the draft document but not verify the document (181). In this case, the draft document service (159) may verify the document after generating the draft document. This will be described later.

FIG. 46 is a diagram illustrating an example of a user interface of a draft document according to an embodiment.

This drawing illustrates an example in which a client creates a draft document without selecting the immediate verification option (178) of the draft document service (159) provided by the platform. First, the draft document service (159) may provide an example template (170) and an upload file attachment option (179). After the draft document is created, the draft document service (159) may provide a draft ID and the current status at each stage.

After an upload file is attached, the draft document service (159) can provide a file verification/conversion menu (182) and a transmission menu (183). Additionally, the draft document service (159) can output a loading spinner while each action is being processed.

Afterwards, the draft document service (159) can send the file to a specific inbox in the message box when the file verification/conversion is completed. At this time, if the file verification/conversion fails, an error log may be displayed and the file may not be sent.

Additionally, each diagram in this drawing can be output sequentially or individually according to each action (draft document creation, upload, verification, transmission, etc.).

FIG. 47 is a diagram illustrating an example of a user interface of a cent document according to an embodiment.

This drawing illustrates an embodiment in which the platform provides a user interface for a central document service (160) when a client selects a central document service (160) menu provided by the platform.

More specifically, the client can check the transmitted document through the sent document service (160). In one embodiment, the sent document service (160) can output information about the transmitted document. Here, the information about the transmitted document can include a message ID, creation time, message type, trading partner, status, and a message payload view menu. In this case, the status can include a status such as delivered, failed, or waiting.

In one embodiment, when a client selects the View Message Payload menu (184), the Sent Document Service (160) may output the message payload in a pop-up window (185). In addition, although not shown in the drawing, the Sent Document Service (160) may provide for downloading the message payload.

Additionally, the sent document service (160) can also search for transmitted documents by filtering them based on at least one of the creation time, trading partner, status, message type, and message ID.

Figure 48 is a flowchart illustrating an application service provision method for providing a web EDI service according to an embodiment.

A processor of a virtualized computing system within a platform providing an isolated workspace of an embodiment of the present invention can receive a web EDI service request from a client using the workspace (S901).

At this time, the Web EDI service can be provided in connection with the application service manager's message box. Web EDI service users can upload files other than standard EDI documents using the draft document service provided by the Web EDI service. Uploaded files are transmitted to the message box, undergoing verification and conversion processes, and then transmitted to the Web EDI service user's partner system.

The embodiment may provide at least one of an inbox document service, a draft document service, and a sent document service through a web EDI service (S903).

Here, the Inbox Document Service is a service for clients connected to the platform to view received documents, the Draft Document Service is a service that performs the document upload, verification, and conversion process before transmission and then actually performs the transmission request, and the Sent Document Service corresponds to a service for viewing or downloading transmitted documents.

Figure 49 is a drawing showing the operation of a scrap adapter according to an embodiment.

According to an embodiment, the instance system (1000) of the present invention may provide a scrap adapter (1400) to a client (300). At this time, the client (300) using the instance system (1000) of the present invention may be, for example, a third-party logistics company.

The scrap adapter (1400) can utilize various services by utilizing the application service manager (2100) of the present invention. More specifically, the platform may provide at least one of a Configuration Service Interface that provides access to configuration settings required for the scrap adapter (1400) to utilize the framework, a Task Service Interface that provides functions related to task processing, a Channel Access Service Interface that provides access to a communication channel, a Message Box Access Service that provides access to a message box, and a Settings Repository Service Interface.

That is, the scrap adapter (1400) enables the client (300) to automatically collect partner data through services such as the message box (2110) service and the settings storage. At this time, the data collected by the client (300) from the partner may generally include at least one of the partner's order data and shipping data. Here, if the client is a logistics company, the partner corresponds to a retailer from which the logistics company collects orders. This will be described in detail later.

If the application service manager (2100) provided by the present invention is not used, the client (300) has the difficulty of having to individually develop all the codes included in the scrap adapter (1400). If the scrap adapter (1400) of the present invention is used, the client (300) can use the various services of the application service manager (2100) that the scrap adapter (1400) can already use, so that the distributor's data can be automatically collected by inputting only the specific setting information described below. In addition, there is an advantage in that other clients (300A, 300B) using the first distributor can use the scrap adapter (1400) of the client (300) that has been previously developed. Of course, in the case of clients A (300A) and B (300B), the setting information for using the scrap adapter (1400) must be input through a separate agent.

In order for the scrap adapter (1400) to automatically collect data from distributors, the client (300) can register account and password information, company information, interval/cron information, and transmission channel information for the scrap adapter (1400) through the agent (350). Here, the company information indicates supplier information, and the interval information indicates the data collection execution cycle of the scrap adapter.

Typically, even when a distributor links data to an ERP system, it is difficult for a client using the ERP system to determine what data has been collected. In contrast, the scrap adapter (1400) of the present invention can determine whether the first data is already collected when collecting data from a distributor. More specifically, the scrap adapter (1400) can prevent the first data from being collected again by marking an index on the first data collected from the distributor. In other words, if the first data has a previously collected record, the scrap adapter (1400) can be configured to collect the second data instead of collecting the first data again.

In one embodiment, the scrap adapter (1400) may transmit data collected from a distributor to the inbox slot of the message box (2110) using the message box transmission module (1401). At this time, the message box transmission module (1401) may transmit the distributor's data to the inbox slot of the message box (2110) as a JSON file or XML file.

FIG. 50 is a drawing illustrating an example of a user using a scrap adapter according to an embodiment.

This drawing is a drawing for explaining the process of an actual user using the web scrap adapter (1400) of the present invention.

More specifically, Suppliers 1 to 3 can produce goods and deliver them to the warehouse of the client (300). Here, the client (300) may be, for example, a third-party logistics company that owns a warehouse.

Retailer A1 and Retailer A2 can order goods from Distributor A (the aforementioned partner) through a web service. In one embodiment, the web scraping adapter (1400) of the present invention can collect order data from retailer A and order data from retailer A2 received by Distributor A. Similarly, the web scraping adapter (1400) can collect order data from retailer B and order data from retailer B1 and order data from retailer B2 received by Distributor B. A client (300) using the web scraping adapter (1400) can directly deliver goods held in a warehouse to the retailers based on the order data from retailers A1 and A2 and retailers B1 and B2 collected through the scraping adapter (1400).

In particular, the web scrap adapter (1400) of the present invention was developed for the client (300) to collect order data of distributor A and distributor B, but since other application services within the platform can be used for the development of the web scrap adapter (1400) as described above, other clients (e.g., client A or client B) can use the web scrap adapter (1400) as is to collect order data of distributor A or distributor B without additional development.

FIG. 51 is a drawing illustrating an example of a user interface of a platform according to an embodiment.

This diagram illustrates the interface provided by a platform when a client accesses a platform that provides application services according to an embodiment. When a client accesses a system initiated by the platform, the platform may provide a user interface menu associated with a user-specific workspace. For details, please refer to the aforementioned embodiment.

In this drawing, the client can access a user interface menu associated with a client-specific workspace on the platform to utilize the scrap adapter described above.

The platform of the present invention can provide a client with a scrap adapter user interface (186) corresponding to a scrap adapter among the adapters installed in a client-only workspace.

The scrap adapter user interface (186) can manage suppliers to be scraped. For example, if the scrap adapter's client is a logistics company, the scrap adapter must collect information on at least one supplier that supplies goods to the distributor in order for the logistics company to collect order data from the distributor.

In one embodiment, the scrap adapter user interface (186) may output a list of at least one supplier (187) of a distributor. More specifically, the supplier list (187) may include information about at least one supplier that supplies goods to the distributor. Information about the supplier may include a group ID, a user ID, a schedule type, a schedule expression, an inbox slot, and whether it is activated. Here, the group ID represents the supplier's ID, and the user ID represents the supplier's user ID. The schedule type may be a method for setting a cycle for the scrap adapter to collect data, such as an interval method or a CRON method. Here, the interval method is a method for repeating a task at regular intervals, and the CRON method is a method for setting a complex and specific time schedule.

A client can input information about a supplier to be scraped into the scrap adapter user interface (186), and the scrap adapter can scrape data based on the input information and then pass it to the inbox slot of the message box of the present invention.

FIG. 52 is a drawing illustrating an example of a user interface of a platform according to an embodiment.

This drawing is a drawing illustrating a menu for managing suppliers to be scraped within the scrap adapter user interface (186) for a client to utilize the scrap adapter described above.

In this drawing, the supplier management menu may include supplier information (188) such as scrap ID, supplier name, group ID, and user ID, and may include scrap information (189) and other information (190). Here, the scrap information (189) may provide the date on which scraping starts (Initial Date), the number of retries when scraping fails (Retry count), the retry interval to wait before retrying when scraping fails (Retry Interval), schedule type, and schedule expression. The other information (190) may include message box inbox slot information, buyer code (e.g., distributor name), delivery information, ordering information, partner information, receipt confirmation information, and order classification information.

When a client enters and saves information in the supplier management menu, the platform of the present invention can automatically collect data based on the information entered by the client using the scrap adapter.

FIG. 53 is a diagram disclosing a data collection method according to another embodiment.

This drawing illustrates an example of data actually collected by the scrap adapter of the present invention. This drawing illustrates a method by which Client A (300A) directly checks order data for at least one distributor online.

By using the scrap adapter of the present invention, the order data on the web as shown in this drawing is automatically collected by the scrap adapter.

For example, client A (300A) can collect information on an order data list (191) for at least one distributor, and individually select the first to n-th order data included in the order data list (191) to collect detailed information on the first to n-th order data. If the scrap adapter of the present invention is not used, client A (300A) must directly download the order data list (191) on the web screen, or individually select the first to n-th order data included in the order data list (191) to download detailed information on the order data. However, if the scrap adapter of the present invention is used, the scrap adapter can automatically collect order data for distributors of client A (300A).

In addition, the scrap adapter can set a filter condition (e.g., scrap only specific orderers, 192) through the other information (190) field of FIG. 51. When the scrap adapter sets a filter condition (190 of FIG. 51), it has the same effect as collecting an order data list (191) according to the filter condition (192) of this drawing.

Figure 54 is a drawing showing the operation of a scrap adapter according to an embodiment.

A processor of a virtualized computing system within a platform providing an isolated workspace can receive scrap adapter setting information from a client using the workspace (S905).

In one embodiment, the platform may provide an application programming interface (API) required for the scrap adapter to use the framework. Here, the API may include at least one of a configuration service interface that provides access to configuration settings, a task service interface that provides functions related to task processing, a channel access service interface that provides access to a communication channel, a message box access service interface that provides access to a message box, and a configuration repository service interface.

In one embodiment, the platform may receive scrap adapter configuration information from a client. The scrap adapter configuration information may include account and password information, company information, cycle information, and transmission channel information. For further details, please refer to the description in FIG. 49.

Based on the scrap adapter configuration information, data of the partner configured by the client can be collected (S907). At this time, an example in which the scrap adapter collects data of the client's partner based on the configuration information entered by the client is described in detail in FIG. 52.

The collected data can be stored in the inbox slot of the message box within the platform (S909).

For this, please refer to the contents described above in Fig. 49.

FIG. 55 is a drawing disclosing an example of an application service providing device according to an embodiment converting data based on a source schema for EDI document data.

In the illustrated example, the application service providing device (6000) may include an instance system (not shown) and a manager system (not shown). The instance system may include a worker node (e.g., Node #N) on which an agent adapter (1350) and a mapping adapter (1370) are installed, and may provide application services to a client (100) and a partner (200).

The manager system (not shown) may include an application service manager (2100), and the application service manager (2100) may obtain data collected from an agent (350) of a client (100) and an agent (450) of a partner (200) from an agent adapter (1350) installed in a worker node.

Accordingly, the application service providing device (6000) according to an embodiment of the present invention may include an agent adapter (1350), a mapping adapter (1370), and an application service manager (2100).

The agent adapter (1350) may include a transceiver (810). The transceiver (810) may receive EDI document data from the agent (350) of the client (100). For example, the EDI document data may be expressed as text data according to a predefined EDI standard (e.g., ANSI X12, EDIFACT). Here, the EDI document data may be referred to as source document data or a term having an equivalent technical meaning thereto. In one embodiment, the EDI document data received from the agent (350) may be stored in a message box (2110) included in the application service manager (2100).

The mapping adapter (1370) may include a schema acquisition unit (6101), a schema mapping unit (6102), and a data conversion unit (6103). In this case, the schema acquisition unit (6101) may acquire a source schema for EDI document data. In this case, the EDI document data may refer to a standard EDI document. For example, the source schema for the EDI document may include a Standard Exchange Format (SEF) and an EDI Exchange Format (EXF) file. In one embodiment, the source schema may be acquired by being uploaded to a resource path by a user in the console.

Additionally, in one embodiment, the schema acquisition unit (6101) can acquire a target schema for target document data. In one embodiment, at least one of the target schema and the mapping script for mapping the source schema and the target schema can be generated based on a user input of the client (100) or partner (200) for a graphical user interface (GUI) of a platform of an instance system (not shown) provided to the client (100) or partner (200).

The schema mapping unit (6102) can map a source schema to a target schema. The schema mapping unit (6102) can set the source schema and the target schema based on user input, and can set a mapping relationship between the source schema and the target schema. In one embodiment, the schema mapping unit (6102) can map the source schema to the target schema based on user input for a graphical tool. This is described in detail below.

The data conversion unit (6103) can convert EDI document data having a first data format into target document data having a second data format based on at least one of a source schema, a mapping script, and a target schema. In one embodiment, the agent adapter (1350) can receive target document data from a message box (2110) and transmit it to an agent (450) of a partner (200).

Figure 56 is a diagram disclosing an example of a source schema for EDI document data according to an embodiment.

In the illustrated example, the application service providing device (6000) may obtain a source schema for EDI document data. The source schema may indicate the structure and format of EDI document data for a specific transaction set or document type for the EDI document data. In one embodiment, the source schema may include a transaction set (6104) and a segment set (6105) for the EDI document data.

In one embodiment, the transaction set (6104) may include at least one EDI transaction representing a business transaction with a partner. In one embodiment, each transaction may be composed of at least one segment included in the segment set (6105) and a delimiter indicating the composition of each segment and data element. For example, the transaction set (6104) may include, but is not limited to, transactions for a deposit advice (CREADV), a cargo insurance policy issuance advice (CIPADV), a cargo insurance application (APPCIP), and an export bill of exchange (collection) application (APPNEG).

In one embodiment, the segment set (6105) may include at least one segment representing EDI data and a hierarchical data structure. For example, the segment may include, but is not limited to, AGR (Agreement identification), AJT (Adjustment details), BGM (Beginning of message), and BUS (Business function) and may include various segments. In one embodiment, each segment may be composed of at least one data element and a delimiter. For example, each segment may be composed of data elements representing letters/numbers (AN), letters (A), numbers (N), and delimiters representing optional items (?), a certain number or more (e.g., + for 1 or more, * for 0 or more), and a minimum length and a maximum length of data ([number:number]).

Additionally, in one embodiment, the delimiter may be configured in various ways according to the EDI standard, for example, ANSI X12 may divide segments with ~, and * may be used within data elements. Additionally, EDIFACT may use single quotes (') when dividing segments, and plus (+) may be used within data elements.

FIG. 57 is a drawing disclosing an example of a user interface for setting a target schema for target document data according to an embodiment.

In the illustrated example, a user interface for setting a target schema for target document data of the present invention may provide a schema editing screen. Here, the schema editing screen may include at least one of a schema editing area (6106) and an annotation area (6107).

In one embodiment, the schema editing area (6106) is an area where a user edits a target schema used in a mapping flow, and an example is shown in this drawing. Here, the schema editing area (6106) represents a data structure for target document data and may represent a hierarchical structure of nodes with names. Here, each node may have a type (Type), such as Int or String.

The Annotation area (6107) corresponds to an area for editing information necessary when the target document data is expressed as text, in addition to the hierarchical structure of the data. Furthermore, the Annotation area (6107) corresponds to an area for editing additional information necessary when recognizing the data as text, in addition to the hierarchical structure of the data. In one embodiment, the Annotation area (6107) may indicate the name and type of the target schema. For example, the name of the target schema may indicate RFC_CREADV, and the type may indicate RecordTypeDef.

In one embodiment, the annotation area (6107) may include an annotation list (6108). Here, the annotation list (6108) may include an annotation name and a document type. In this case, multiple annotations may be added for each node, and multiple annotations with the same name cannot be added. Each annotation may have multiple types depending on the document type (XML, JSON), and each annotation may have unique properties (arguments).

In one embodiment, the annotation area (6107) may further include a user annotation list (6109). The user annotation list (6109) may further include name and namespace as unique attributes (arguments) corresponding to existing annotations, but these are not mandatory values. That is, both name and namespace may be optionally added. The name may be used to describe the role or meaning of the corresponding argument. For further details, please refer to the above-described drawings.

For example, a target schema (6110) for XML document data corresponding to a deposit notice can be set through editing by user input.

FIG. 58 is a drawing disclosing an example of a user interface for setting up a source schema and a target schema according to an embodiment.

In the illustrated example, a user interface for setting a target schema for target document data may provide a schema setting screen. Here, the schema setting screen may include at least one of a source schema setting area (6111) and a target schema setting area (6112). In one embodiment, a target schema setting area (6112) may be provided as a subsequent screen from the source schema setting area (6111).

The source schema setting area (6111) may include at least one of a resource path, a resource file, and an EDI transaction for the source schema. Here, the resource path may indicate an EDI schema file path for EDI document data. The resource file may indicate a schema file path for the source schema. The EDI transaction may indicate an EDI transaction for the source schema to be performed with a partner.

The target schema setting area (6112) may include at least one of a resource path, a resource file, and an EDI type for the target schema. The resource path may indicate the path to an EDI schema file for EDI document data. The resource file may indicate the path to a schema file for the target schema. The EDI type may indicate the type of target schema to be performed with the partner.

In one embodiment, the CREADV of 911.exf can be designated as the source schema (EDI) and the RFC_CREADV schema of RFC_CREADV.schema can be designated as the target schema (XML) through the source schema setting area (6111) and the target schema setting area (6112).

FIG. 59 is a diagram disclosing an example of a user interface for mapping a source schema and a target schema according to an embodiment.

In the illustrated example, a user interface for mapping a source schema and a target schema may provide a mapping program editing screen. Here, the mapping program editing screen may include a mapping program area (6113), a schema mapping area (6114), and a mapping expression area (6117).

Here, the mapping program area (6113) may include the development tool palette and development GUI code area described above. That is, in the mapping program area (6113), the user can arrange the necessary blocks (statements) in flow order to perform conversion between a complex source schema and a target schema.

Additionally, in one embodiment, a user may select a MAP block from among the development GUI codes being output within the mapping program area (6113). Accordingly, the user interface may output the source schema and target schema corresponding to the MAP block to the source schema area (6115) and target schema area (6116), respectively, contained within the schema mapping area (6114).

More specifically, the source schema area (6115) represents information about the data schema before conversion. In one embodiment, the user can add or delete information about the source schema. The target schema area (6116) represents information about the data schema after conversion. The source schema area (6115) and the target schema area (6116) facilitate connections between source and target schema nodes. Furthermore, in one embodiment, the user interface can output mapping lines between nodes included in the source schema and nodes included in the target schema. Through this, the user can visually determine whether a node in the source schema is mapped to a node in a target schema.

Additionally, in another embodiment, when the user interface receives an input signal for selecting a node included in the source schema and then dragging and dropping it to a node included in the target schema, the user interface can automatically output the corresponding mapping expression to the mapping expression area (6117).

The mapping expression area (6117) is an area that performs actual mappings between nodes. It is displayed when a mapping block is selected from the preceding blocks (Statements), allowing multiple mapping expressions to be inserted between each node. In other words, it corresponds to an area that sets detailed values of the mapping expression. For further details, please refer to the above-mentioned content.

Through this, according to the present invention, a source schema can be mapped to a target schema for target document data using a graphical tool. Furthermore, EDI document data can be converted into target document data (6118) (e.g., XML document data) based on a mapping script that includes at least one of statement information representing the grammar of the source schema, the target schema, and a programming language, or expression information representing a specific result value.

Figure 60 is a flowchart showing an example of a method for providing an application service according to an embodiment of the present invention for converting data based on a source schema for EDI document data.

In a computing system that manages a platform that provides clients with isolated workspaces where application packages are executed, a source schema for EDI document data is acquired (S1001). In one embodiment, the source schema may include metadata representing at least one of an EDI transaction, segment, and data element for the EDI document data.

A source schema is mapped to a target schema for target document data using a graphical tool (S1003). In one embodiment, a target schema for target document data is set, at least one of a resource path, a resource file, and an EDI transaction for the source schema and the target schema is determined, and at least one of a hierarchically structured segment and data element of the source schema is mapped to the target schema based on at least one of the resource path, the resource file, and the EDI transaction. For this, please refer to the description above in FIG. 59.

EDI document data is converted into target document data based on the mapping (S1005). In one embodiment, data elements in the EDI document data may be parsed, and the parsed data elements may be converted into the data format and data structure of the target document data based on the mapping between the source schema and the target schema. In one embodiment, after step S1005, the converted target document data may be transmitted to the partner. For this purpose, please refer to the contents described above in FIGS. 55 and 59.

110, 120, 130, 310: Client
200, 320: Partner
300: Client or Partner
350: Agent
351: Agent Control Processing Unit
353: Transmission and reception setting processing unit
357: Transmitter and receiver
1000: Instance System
1100: Coordinator
1110, 1120, 1300, 3110, 3210: Nodes
1330, 1115, 3115, 3215: Settings storage
1350: Agent Adapter
1351: Agent Control Unit
1352: Transmission and reception settings section
1353: Transmission and reception processing unit
1370: Mapping Adapter
1380: Integrated Package
1390: EDI Adapter
1500, 1510, 1520, 1530: Workspace
1610: API
1700: Framework Layer
1800: Virtualization Layer
1900: Resource Layer
2000: Manager System
2100: Application Service Manager
2110: Message Box
3000: Development Workspace
4000: Interface Governance Platform
4100: Governance API
6000: Application Service Provider

Claims (11)

In a computing system that manages a platform that provides clients with isolated workspaces in which application packages run, a step of obtaining a source schema for EDI document data;
A step of mapping the above source schema to a target schema for target document data using a graphical tool; and
A step of converting the EDI document data into target document data based on the above mapping;
including,
How to provide application services.
In the first paragraph,
The source schema includes metadata representing at least one of an EDI transaction, segment, and data element for the EDI document data.
How to provide application services.
In the first paragraph,
The above mapping steps are:
A step of setting a target schema for the above target document data;
A step of determining at least one of a resource path, a resource file, and an EDI transaction for the source schema and the target schema;
A step of mapping at least one of the hierarchically structured segments and data elements of the source schema to the target schema based on at least one of the resource path, resource file and EDI transaction;
including,
How to provide application services.
In the first paragraph,
The above conversion step is,
A step of parsing data elements from the above EDI document data;
A step of converting the parsed data elements into a data format and data structure of the target document data based on the mapping of the source schema and the target schema;
including,
How to provide application services.
In the first paragraph,
After the above conversion step,
A step of transmitting the converted target document data to a partner;
including more,
How to provide application services.
a database that stores data; and
Including a processor for processing the above data,
The above processor,
In a computing system that manages a platform that provides clients with isolated workspaces where application packages run, obtains the source schema for EDI document data,
Map the above source schema to the target schema for the target document data using a graphical tool,
Converting the EDI document data into target document data based on the above mapping,
Application service providing device.
In paragraph 6,
The source schema includes metadata representing at least one of an EDI transaction, segment, and data element for the EDI document data.
Application service providing device.
In paragraph 6,
The above processor,
Set the target schema for the above target document data,
Determine at least one of the resource path, resource file, and EDI transaction for the source schema and target schema,
Based on at least one of the resource path, resource file and EDI transaction, at least one of the hierarchically structured segments and data elements of the source schema is mapped to the target schema.
Application service providing device.
In paragraph 6,
The above processor,
Parse the data elements from the above EDI document data,
Based on the mapping of the source schema and the target schema, converting the parsed data elements into the data format and data structure of the target document data.
Application service providing device.
In paragraph 6,
The above processor,
Sending the above converted target document data to the partner,
Application service providing device.
In a computing system that manages a platform that provides clients with isolated workspaces where application packages run, obtains the source schema for EDI document data,
Map the above source schema to the target schema for the target document data using a graphical tool,
A storage medium storing a computer-executable program that provides an application service for performing a step of converting the EDI document data into target document data based on the above mapping.