CN111258567A

CN111258567A - Service code development processing method and device

Info

Publication number: CN111258567A
Application number: CN201811461099.XA
Authority: CN
Inventors: 张群辉; 沈东佳; 冯微峰; 方小瑞; 马莉亚; 夏斐; 尹长江; 潘玉民; 段亚军; 高鹏程; 曾露; 张黎静; 祁小彦
Original assignee: Alibaba Group Holding Ltd
Current assignee: Alibaba Group Holding Ltd
Priority date: 2018-12-01
Filing date: 2018-12-01
Publication date: 2020-06-09
Anticipated expiration: 2038-12-01
Also published as: CN111258567B

Abstract

The embodiment of the application discloses a service code development processing method and a service code development processing device, wherein the method provides a plug-in for a development tool, and the following processing is executed through the plug-in: creating a first window and a second window, wherein the first window is used for code editing, the second window comprises a first operation option used for determining a service code type and initiating code editing, and the service code type comprises: a service interface code and a service implementation code; and after receiving an operation request through the first operation option, creating a code library, and issuing the received service code to a server, so that a service caller initiates the call of the service realization through the service interface to obtain the service on the corresponding node. By the aid of the method and the device, the service granularity-based code development and release can be supported flexibly, access of new merchants can be realized quickly at low cost, and meanwhile, code development and release based on service granularity are supported better.

Description

Service code development processing method and device

Technical Field

The present application relates to the technical field of service code development, and in particular, to a method and an apparatus for developing and processing service codes.

Background

In an online and offline combined business mode such as 'new retail', a retailer can provide information of commodity objects through an application program (App) on a line, and a user can browse, purchase and the like through the App on the line. Meanwhile, the retailer can set up an off-line physical store, and the user can purchase the commodity object through the off-line physical store. Meanwhile, the online order may be subjected to a series of processes such as shipment by an offline physical store, and finally delivered to a delivery destination designated by the user. However, some retailers may be limited in their own resources or capabilities, and cannot provide perfect services such as delivery and delivery for users, and even when goods are put on shelves, there may be some difficulties, which may lead to low efficiency and high error rate. In order to enable such retailers to also participate in the "new retail" system, the "new retail" platform side can provide services to the retailer, such as standardized process flow services, and the retailer can complete the online and offline combined sales link by purchasing the platform side services. For example, a retailer may purchase "on shelf" services, at which point the platform side may offer the retailer a corresponding solution, and so on.

Typically, services on a particular business link may be provided by the platform side, but as systems evolve, more and more external merchants need to collaborate with the "new retail" platform. For example, an external merchant may also be able to offer "on-shelf" services, and may wish to participate in a "new retail" system, so that other retailers may also purchase the services offered by the external merchant to address certain problems, and further, so that such external merchant may also be able to serve as another source of revenue by selling such services.

However, the merchant who can provide the service related to the business link usually uses a specific ERP system to manage various information and data. For example, merchant a uses an ERP system inside, and the specific way of implementing the goods shelving process inside may be different from the default shelving process on the platform side of the "new retail" system. At this time, when an external merchant accesses the platform, it may be desirable to continue to use the processing method that is used internally, rather than using the platform side uniformly, and the latter needs to upgrade and upgrade the software and hardware system inside the external merchant, which may be relatively high in cost.

Therefore, how to flexibly support a business scenario and perform access of a new business quickly and at low cost becomes a technical problem to be solved by a person skilled in the art.

Disclosure of Invention

The application provides a service code development processing method and device, which can support the service granularity-based code development and release better while flexibly supporting a service scene and quickly accessing a new merchant at low cost.

The application provides the following scheme:

a service code development processing method provides a plug-in for a development tool, and the following processing is executed through the plug-in:

creating a first window and a second window, wherein the first window is used for code editing, the second window comprises a first operation option used for determining a service code type and initiating code editing, and the service code type comprises: a service interface code and a service implementation code; the service interface is defined according to nodes in a commodity object service process, and the service realization is provided according to the definition information of the service interface;

and after receiving an operation request through the first operation option, creating a code library, and issuing the received service code to a server, so that a service caller initiates the call of the service realization through the service interface to obtain the service on the corresponding node.

A service code development processing apparatus which is a plug-in of a preset development tool, comprising:

a window creating unit, configured to create a first window and a second window, where the first window is used for performing code editing, the second window includes a first operation option used for determining a service code type and initiating code editing, and the service code type includes: a service interface code and a service implementation code; the service interface is defined according to nodes in a commodity object service process, and the service realization is provided according to the definition information of the service interface;

and the code issuing unit is used for creating a code library after receiving the operation request through the first operation option and issuing the received service code to the server so that the service calling party initiates the calling of the service implementation through the service interface to obtain the service on the corresponding node.

An electronic device, comprising:

one or more processors; and

a memory associated with the one or more processors for storing program instructions that, when read and executed by the one or more processors, perform operations comprising:

after receiving an operation request through the first operation option, creating a code library, and after receiving a service code through the first window, issuing the service code to a server so that the server stores the corresponding relationship between the service interface and the service implementation, and a service caller initiates the call of the service implementation through the service interface to obtain the service on the corresponding node.

According to the specific embodiments provided herein, the present application discloses the following technical effects:

according to the embodiment of the application, the standard operation program flow in the commodity object service flow is divided according to the logical node granularity and abstracted to form the service interface, then the service implementation is provided for the service interface, so that the service implementation corresponding to different nodes in the flow is mutually independent, the corresponding flow engine is provided, the routing can be carried out to a specific service implementation level, each service implementation can be independently developed, independently deployed and independently called, the service scene can be flexibly supported, and the access of new merchants can be rapidly carried out at low cost. Meanwhile, a plug-in can be introduced into the integrated development tool, and the plug-in can directly provide a first operation option for determining the service code type and initiating code editing in the integrated development tool interface, and then a developer can execute specific development work on the service granularity, wherein the specific development work comprises the steps of providing service implementation codes for the service interfaces according to the definition of the new service interfaces, combining the existing service interfaces into the new service interfaces, and the like. Thereafter, the service code can be seamlessly released from the development tool directly to the serverless platform without switching back and forth between multiple systems or platforms, so that the landing of the above scheme can be better realized.

In addition, the service code can be managed in a full life cycle, an engineer only pays attention to the service in the whole process, the application is not paid attention to, and the code management is not required to be paid attention to.

Of course, it is not necessary for any product to achieve all of the above-described advantages at the same time for the practice of the present application.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings needed to be used in the embodiments will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings without creative efforts.

FIG. 1 is a schematic diagram of a system provided by an embodiment of the present application;

FIG. 2 is a flow chart of a method provided by an embodiment of the present application;

FIGS. 3-1 through 3-3 are schematic diagrams of interfaces provided by embodiments of the present application;

FIG. 4 is a schematic view of an apparatus provided by an embodiment of the present application;

fig. 5 is a schematic diagram of an electronic device provided in an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments that can be derived from the embodiments given herein by a person of ordinary skill in the art are intended to be within the scope of the present disclosure.

It should be noted that, in the service mode of online and offline combination, such as "new retail", the service scenario is complex, the service link is long, and a whole set of middlebox system from the supply chain to the user end is implemented. In this process, the business side in the service platform often needs to process multiple standard work flows. For example, for a business party facing a consumer, it may involve processing downstream flows, shipping flows, and the like. For business parties facing merchants, it may be more necessary to handle the shelving process, the warehouse dispatching process, the warehouse replenishment process, the warehouse distribution process, the commodity price modification process, and the like. Each process may include a plurality of service logic nodes, for example, for a commodity shelving process, a plurality of nodes such as picking- > packing- > boxing- > shelving are included.

In the prior art, a platform side uses an application-based development mode, and a developer develops code according to application dimensions, so that one application usually includes implementation of a plurality of nodes in a specific process. For example, for the goods shelving process in the foregoing example, which includes multiple nodes such as picking- > packaging- > boxing- > shelving, in the prior art, the implementation codes on the nodes in the process are combined together, bound in the same unit, developed together, deployed together, and provided with services to the outside together. At this time, assuming that, for the packaging service in the above flow, besides the platform side can provide the corresponding implementation, two cooperating merchants A, B can also provide respective implementations, and the packaging service needs to be added to the above flow, but the original implementation in the flow may not meet the requirements of the new merchant. Such as: the original flow is Start- > node A- > node B- > node C- > End. When a new merchant needs to join the process, the service implementation corresponding to the node A is implemented according to a default mode of the platform, the requirement of the merchant A cannot be met, and an implementation mode needs to be added to the node A based on the node A: "implementation of a service 2". At this time, if a conventional flow engine is used, there may be the following schemes: scheme 1: redefining a new flow, still comprising 'Start- > node A- > node B- > node C- > End', and modifying the implementation mode of 'service A' into 'implementation 2' of A service. Scheme 2: the original flow is used, but the code corresponding to the flow needs to be modified, and a conditional statement is written in the code to judge which calling service is selected, namely, a hard coding mode. Scheme 3: on the basis of the original flow, a branch flow is added, namely a selection node is added, a judgment condition is added on the selection node, and meanwhile, an option corresponding to the added condition selects which service is called through the judgment condition. Each of these three schemes has drawbacks: scheme 1, need to maintain many sets of flows, the maintenance cost is high. Once the flow template is modified, all corresponding flows need to be modified. In the scheme 2, the business logic is realized by depending on codes, and once a new process is accessed, the codes corresponding to the process need to be modified, which is an invasive implementation mode. In the scheme 3, once a new merchant accesses, the flow configuration needs to be modified, and a relatively steady flow cannot be maintained.

In the embodiment of the present application, in order to support a business scenario more flexibly and perform access of a new merchant quickly and at low cost, as shown in fig. 1, a standard service interface (may be referred to as an SPI in the embodiment of the present application) may be abstracted from a standard job procedure flow in a service platform such as "new retail" by taking a node as a unit, and a first system 101 may be provided and may be used to define a specific service interface and perform registration; the definition information of the service interface may be provided to a specific service provider (for example, the service platform itself, or other external merchants, etc. in this embodiment, referred to as the third system 103), and the service provider may provide a specific service implementation (which may be referred to as a bundle in this embodiment) according to a standard job interface specification corresponding to a specific service. That is to say, in the embodiment of the present application, a service logic node in a specific flow no longer corresponds to a certain fixed specific implementation, but exists in the form of an interface, and when defining a service interface, only the entry, exit, function, and the like of the service logic node need to be defined, and a specific implementation code does not need to be provided. In other words, a service interface only needs to define what functions, what entries are needed and what entries are needed, and no specific implementation code needs to be provided. A specific service provider may provide a plurality of different service implementations for a specific service interface, for example, for a service interface such as "pick" at the service interface level, it is not necessary to determine how to implement the pick function specifically, but merchant a can provide a specific pick service, and may provide a specific service implementation code for the service interface, that is, merchant a provides a service implementation code for the pick service according to the specific pick implementation logic of merchant a. In addition, if the merchant B can also provide a specific picking service, a corresponding picking service implementation code may also be provided according to a specific picking implementation logic inside the merchant B. By the method, mutual decoupling between different nodes in the business process is realized, and services on different nodes can be independently developed and deployed and are independently provided for the outside. Moreover, for the same service interface, a plurality of different service implementation codes can be provided by a plurality of different service providers and respectively registered in the process engine subsystem, so that the same service interface can be implemented in a 'multi-state'.

That is, in the embodiment of the present application, a specific service interface may be abstracted by a platform side, and then a specific service implementation code may be provided by a service provider, where the service implementation code of each service provider may be developed according to a service implementation logic in an ERP (enterprise management planning) system inside the service provider. In addition, the specific service implementation code provided by the service provider may be directly stored in the server of the service provider itself, and when subsequently called by the specific service caller, the service implementation code may also be run on the server of the service provider itself, execute the specific operation according to the implementation logic inside the service provider, and return the processing result to the service caller.

After abstracting and defining the service interface in the above manner and providing at least one service implementation for a specific service interface, a service caller (e.g., a specific business caller, etc., which may be referred to as the second system 102 in this embodiment) may call one specific service implementation under the service interface through the specific service interface, so as to obtain a corresponding service. When the service caller specifically calls the service, the service caller can specify the id or name of the service to be called, and can also specify the information of the specific service implementation to be called, and then the specific flow engine system routes the specific call request to the service address corresponding to the specific service implementation. Specifically, when the service is specified, specific parameter information may be set in the calling code. In order to facilitate the setting of the calling parameters by the service caller, the service provider may set a specific routing rule when providing the service implementation code. For example, in one form, identification information such as id or name of a specific service implementation may be directly specified, so that the flow engine can directly locate the specific service implementation code to be called through the id or name of the service implementation. Or, in another implementation form, the specification may also be performed by a regular operation, and the like, in this case, the specific incoming parameter may be some indirect information, for example, information such as a warehouse type and a warehouse Id, and then the specific service implementation code is located by a regular operation.

For example, in a service system in a "new retail" mode, in order to enable standard services of the system to access ERP systems of different partners on a standard service link of the system, so as to implement diversification of a certain service node, embodiments of the present application abstract each service on a specific service link, and define a standard interface of the service, which may be referred to as an SPI, for example, including a pick-up service interface, a packaging service interface, an on-shelf service interface, and the like. The specific implementation of the service is called Bundle, one SPI can be implemented by a plurality of bundles, and the service implementation is polymorphic. For example, in the above commodity shelving process, the four nodes including picking, packaging, boxing and shelving may be abstracted into four service interfaces, which are a picking service interface, a packaging service interface, a boxing service interface and a shelving service interface, respectively, in the embodiment of the present application. The SPI of the picking service interface can be realized by the service provided by the service provider 1; the SPI may have a Default implementation (Default Bundle) provided by the service provider a, an implementation (e.g., darnfaabundle) provided by the service provider 2, and so on.

After the abstraction of the service interface is performed and the service implementation is developed on the service granularity, the service can be registered in the service system, so that the service in a specific entity shop can be conveniently called to obtain a specific function through the calling of the service implementation. For example, a service caller in the entity store a may call implementation of a packaging service provided by the service provider 1 to implement a packaging function, and call implementation of an on-shelf service of the service provider 2 to implement an on-shelf function; the service invoker in the entity store B may invoke the implementation of the picking service provided by the service provider 1 to implement the picking function, invoke the implementation of the shelving service of the service provider 2 to implement the shelving function, and so on. That is to say, in the process of implementing the standard operation flow, the same service invoker client may use the service implementations provided by a plurality of different service providers to jointly solve the specific problems in the actual service scenario by arranging the implementations corresponding to the plurality of different services, including setting the invocation relationship between the different services, and the like.

In which, whether the definition of the service interface or the creation of the service implementation involves some code editing operations, for example, the definition code of the service interface, the implementation code of the service implementation, and so on. In the embodiment of the present application, the development of the code may be implemented by a Serverless architecture. The Serverless architecture is a technical concept that has been rapidly developed in recent years, and based on the Serverless architecture, a developer does not need to deploy, configure or manage server services, and the server services required by code running are all provided by a cloud platform. However, in the present embodiment, since the work granularity switches from monolithic application to monolithic service/function, from the past: "building a framework running on a server and responding to a plurality of events" becomes: "build/use a microservice or a microservice to respond to an event". Correspondingly, according to the development of application dimensions in the past, since each service is bound in the same unit, under a serverless architecture, services and functions need to be split, and one application is split into decoupled micro-services and then split into functions, which is a matter with huge workload and difficulty.

In addition, the code developed by the code development tool in the prior art needs to be submitted or released in a manner of a Web page or the like corresponding to the service platform provided in the embodiment of the present application. That is, the development operation of the code and the submission, construction, deployment, etc. of the code are split, the developer needs to switch back and forth among multiple sets of systems, the working efficiency is low, and the management operation of the full life cycle of the code cannot be realized.

Therefore, in the preferred embodiment of the application, plug-ins can be provided for the existing development tools, and the development framework provided by the embodiment of the application can be used for directly registering, developing, deploying and managing in service dimension, so that the Serverless framework is naturally supported. That is to say, the plug-in tool can help the definition of the service and the provision of the service implementation provided in the embodiment of the present application to more conveniently implement the ground and improve the development efficiency.

Specifically, in the embodiment of the present application, as long as the service platform provided in the embodiment of the present application is desired to be added, the plug-in provided in the embodiment of the present application may be installed in the development tool of the service platform, regardless of the service interface definer or the service implementation provider. In a presentation window (explorer) of the development tool, a presentation window corresponding to the plug-in can be created, and a list of service interfaces existing in the service platform can be presented in the presentation window and can be presented in a classified manner. In addition, an operation option for newly establishing a service interface or for viewing details of the service interface and providing operation such as service implementation for a specified service interface can be provided. After receiving an operation request through the newly-built service interface or the operation option for providing service implementation, the code library can be automatically created, a window for code editing is created, a developer can directly edit codes in the window, and in addition, one-click operations such as code construction, deployment, release and the like can also be performed. In addition, in the embodiment of the present application, in order to further reduce the workload of the developer, a template may be provided in advance, and when the window for performing code editing is provided, the code library may be initialized at the same time, and an initial code is provided, and in the embodiment of the present application, since the plug-in of the service platform is directly installed in the development tool, all dependency information except a specific business code may be included in the initial code. In this way, a developer only needs to edit specific service codes in the code editing window, and other initialization works and the like do not need to pay attention.

That is to say, in the embodiment of the present application, since a developer naturally adds a service version under a code development tool according to the dimension of an atomic service, it is determined that development is performed based on the development framework, and the development is naturally a faas (function As a service) and no service splitting is required; also, since the granularity of service splitting is small enough that one engineer can be responsible for one service, no change-based code branching is necessary. Therefore, in the embodiment of the present application, the development mode is a backbone development mode by default, and by integrating a code development tool (e.g., IDEA, etc.) and a code management tool (e.g., gitlab, etc.), the creation and detection of a code library to the local is completed by default, and the backbone development mode is used, that is, each service implementation belongs to a backbone code, and an operation of creating multiple branches is not required. In specific implementation, a service version can be newly added to a code development tool according to a service/interface level, and then the code development tool can automatically create a code library and a backbone branch, and can develop and submit codes based on codes automatically detected to the local. During construction and deployment, the function integrated into the plug-in of the development tool can be used for one-key construction and deployment to a serverless platform. It can be seen that the development framework in the embodiment of the present application is different from the conventional development framework in that: because the development, deployment and management are carried out according to the mode of the atomization service, the application does not need to be split into the service granularity, and a server framework is supported naturally; moreover, the functions of the code development tool and the code management tool can be integrated, the plug-in can automatically generate a code base and detect the code base to be local, and one-key construction and deployment can be carried out on a serverless platform.

Thus, in the embodiments of the present application, a complete new service can be provided from scratch (code development in the service dimension, rather than the traditional application dimension), and seamlessly released to the full lifecycle management of the serverless platform. In the process, engineers only need to pay attention to the service and not to pay attention to the application, and the engineers do not need to pay attention to code management because the code base is automatically created and branch management is carried out according to the version rules of the service, and the engineers only need to double click one service in the code development tool to carry out code development.

In specific implementation, referring to fig. 2, an embodiment of the present application provides a service code development processing method, referring to fig. 2, which provides a plug-in for a development tool,

the specific integrated development tools may be various, and in the specific implementation, different plug-ins may be provided for different integrated development tools, and the functions of the plug-ins are the same, but may be different in the aspects of related interfaces and the like in order to adapt to the specific integrated development tools. Alternatively, in another implementation, a plug-in of a unified integrated development tool may be provided, and a developer needing to add a process may use the specified integrated development tool to develop code.

After the plug-in is installed in the code development tool, the following processing can be executed by the plug-in:

s201: creating a first window and a second window, wherein the first window is used for code editing, the second window comprises a first operation option used for determining a service code type and initiating code editing, and the service code type comprises: a service interface code and a service implementation code; the service interface is defined according to nodes in a commodity object service process, and the service realization is provided according to the definition information of the service interface;

in the embodiment of the present application, the service code specifically to be edited may specifically include a definition code of a service interface, an implementation code of service implementation, and the like, and various different types of codes may be developed by a code development tool in which the plug-in is installed, and may be issued in one key. Therefore, in the embodiment of the present application, the specific service code is distinguished into two types, a service interface code and a service implementation code. For two different types of codes, different processing modes can be adopted when the codes are specifically issued and the like.

After the development tool is started, as shown in fig. 3-1, a first window 301 and a second window 302 may be created, where the first window 301 may be specifically used for code editing, and the second window 302 may be used for displaying information related to a relevant service interface, service implementation, and the like in the embodiment of the present application, where the information may include a first operation option for initiating code editing.

The information related to the relevant service interface, the service implementation, and the like may be specifically stored in the server, for example, taking a service interface of a fulfillment category as an example, a specific storage manner may be as shown in table 1:

TABLE 1

In an initial state, a defined list of service interfaces may be exposed in a second window. Specifically, when the service interface list is displayed, classified display may be performed, for example, in the example shown in fig. 3-1, the category information of the service interface is mainly displayed, and after each category name is clicked, as shown in fig. 3-2, a specific service interface list included in the category may be expanded and displayed, and the like. The specific service interface list information may be pulled from the service configuration platform, that is, after the specific service interface is defined, the specific service interface list information may be registered with the process engine subsystem service end and may be recorded in the service configuration platform. Thus, the service configuration platform records information of all the defined service interfaces. Accordingly, the code editor can be exposed through the plug-in the development tool.

In this embodiment, a specific code editor may be a platform side that defines a service interface, or may also be a service provider that needs to provide a service implementation code, or may even be a service caller, for example, when a certain service caller needs to combine two or more services into another new service in the process of actually calling the service, the new service interface may also be combined in a manner that needs to perform code editing, and so on. Therefore, the service code includes a definition code of the service interface, or an implementation code of a service implementation provided for a specific service interface, or a combination code for combining at least two existing service interfaces into a new service interface, and accordingly, the specific first operation option may be various.

For example, one of them may be a first operation option for defining a new service interface, at which time a service definition code regarding the service interface may be received through the first window. Specifically, the service definition code may specifically include codes for defining an entry, an exit, and a function of the service interface.

Or, the first operation option for initiating code editing includes: a first operation option for providing a service implementation for a specified service interface to receive implementation code information regarding the service implementation through the first window.

Specifically, when the first operation option for providing a service implementation for a specific service interface is provided, the first operation option may be provided after selecting to view the detail information of a certain service interface on the basis of the foregoing fig. 3-2. For example, as shown in fig. 3-3, when a service provider specifically clicks and views a certain service interface, the service provider may further display list information of the existing service implementation corresponding to the service interface, and may further include information about a last reviser, a last revision time, a total number of calls, a number of changes, a number of methods included in the current version, and the like of the service interface. In addition, the first operation option described above, for example, a button in the word "new Bundle" as shown in fig. 3-3, or the like, may also be provided in the interface. In the example shown in fig. 3-3, the service interface is specifically "performing operator collaboration service-operator", and in this case, the information corresponding to the service interface may be specifically shown in the following table 2:

TABLE 2

Additionally, the first operational option for initiating code editing includes: a first operation option for combining at least two existing service interfaces into a new service interface by defining a call relationship between the at least two existing service interfaces, so as to receive combination code information on the new service interface through the first window.

For example, a service a calls a service B to implement a function that is commonly used in a system, and thus, in the process of defining a service, the service a and the service B may be packaged to be combined into another service C. Therefore, when the function needs to be realized subsequently, the service C is called directly, and the service A does not need to be called first and then the service B is called in the service A.

S202: and after receiving an operation request through the first operation option, creating a code library, and issuing the received service code to a server, so that a service caller initiates the call of the service realization through the service interface to obtain the service on the corresponding node.

After receiving the code editing request, the plug-in the embodiment of the application may automatically perform an operation of creating a code library without manual creation by a developer, and then may receive the service code through the first window. In addition, in a preferred embodiment, after receiving an operation request through the first operation option, an initialization code may be provided through the first window according to a preset template. Such initialization code may specifically include definitions of some dependencies, and so on. That is, in the embodiment of the present application, some initialization codes may be automatically generated, so that a developer no longer needs to pay attention to implementation of such initialization codes, and thus, efficiency may be improved. Even in specific implementation, except for the code related to specific business logic, the code can be automatically provided in the initialization code, so that a developer only needs to pay attention to the code implementation related to the specific business logic, and does not need to pay attention to other information such as dependency relationship and the like. After the work of editing the service code and the like is completed, the service code can be directly released to the service configuration platform in the embodiment of the application in the current development tool, and the operation of registering the service end of the process engine subsystem and the like can be completed. That is, editing and publishing specific code can be done within the same development tool without having to switch back and forth between multiple tools or systems.

In addition, in the embodiment of the application, other related operations related to the full life cycle of the specific service code can also be provided. For example, whether the newly defined service interface is successfully defined may be tested, a test result may be obtained, and a second operation option for checking whether the service interface is successfully defined may be provided; the second operation option may be provided by a right mouse button option, or may be provided by other shortcut keys, and so on. After receiving an operation request through the second operation option, the test result may be provided. For example, after a user completes definition of a service interface, the user may right click information such as the name of the service interface, and query whether the definition is successful, etc.

In addition, the corresponding relation between the service interface and the service realization can be recorded; providing a third operation option for viewing the service interface information to which the service implementation belongs; and after receiving the operation request through the third operation option, providing the service interface information to which the service implementation belongs. For example, in a specific implementation, it may be queried whether a certain entry corresponds to a bundle, which service interface belongs to, and the like.

In this embodiment of the present application, because multiple service providers can provide multiple different service implementations for the same service interface, in other words, for the same service interface, the second window can also provide the service implementation list information corresponding to the specified service interface, so that the user can query the service implementation condition corresponding to each service interface, and so on.

In addition, during specific implementation, a fourth operation option for constructing, deploying and publishing the received service code may be provided, and after an operation request is received through the fourth operation option, one-click construction and deployment of the service code may be realized, and then the service code may be published. The construction is to compile a development language in the service code to generate a language recognizable by a machine and to generate a command packet. The deployment process mainly deploys a specific instruction packet to a specific server. The service implementation code may be specifically deployed in a server of a service provider, and in specific implementation, the server of the service provider may exist in a distributed server cluster, so that the service implementation code may also be stored in a plurality of different servers, and when subsequently specifically invoked, a service address may be selected from the servers through a certain load balancing algorithm to provide a specific service for a service invoker.

In addition, during specific implementation, a fifth operation option for performing version update on the released service code can be provided, so that a developer can directly perform operations such as version update on the released code in a development tool.

Therefore, in the embodiment of the application, a plug-in can be introduced into the integrated development tool, and the plug-in can directly create a list for showing specific service interface information in the integrated development tool interface, and then a developer can perform specific development work on the service granularity. Including the definition of a new service interface, providing service implementation code to the service interface, combining existing service interfaces into a new service interface, and so on. Thereafter, the service code can be seamlessly released to the serverless platform directly from the development tool. In addition, full lifecycle management can also be performed on service code, in which process engineers are only concerned with services and not applications, and they do not need to be concerned with code management.

Corresponding to the foregoing method, an embodiment of the present application further provides a service code development processing apparatus, where the apparatus is a plug-in for provisioning a development tool, and referring to fig. 4, the apparatus may include:

a window creating unit 401, configured to create a first window and a second window, where the first window is used to perform code editing, and the second window includes a first operation option used to determine a service code type and initiate code editing, where the service code type includes: a service interface code and a service implementation code; the service interface is defined according to nodes in a commodity object service process, and the service realization is provided according to the definition information of the service interface;

a code issuing unit 402, configured to create a code library after receiving the operation request through the first operation option, and issue the received service code to the server, so that the service caller initiates a call to the service implementation through the service interface to obtain the service on the corresponding node.

In a specific implementation, the apparatus may further include:

and the code initialization unit is used for providing an initialization code through the first window according to the template corresponding to the service code type after receiving an operation request through the first operation option.

Wherein the initialization code includes all dependency codes except business logic codes so as to receive code information related to business logic only through the first window.

Wherein the first operational option comprises: a first operation option for defining a new service interface, so as to receive a service definition code related to the service interface through the first window, wherein the service definition code comprises codes for describing the functions, the functions and the participation of the service interface.

At this time, the apparatus may further include:

and the test unit is used for testing whether the newly defined service interface is successfully defined or not to obtain a test result, providing a second operation option for checking whether the service interface is successfully defined or not, and providing the test result after receiving an operation request through the second operation option.

Additionally, the first operational option includes: a first operation option for providing a service implementation for a specified service interface to receive implementation code information regarding the service implementation through the first window.

At this time, the apparatus may further include:

the information providing unit is used for providing a third operation option for viewing the service interface information to which the service implementation belongs; and after receiving an operation request through the third operation option, providing the service interface information to which the service implementation belongs.

In addition, the first operation option may also include: a first operation option for combining at least two existing service interfaces into a new service interface by defining a call relationship between the at least two existing service interfaces, so as to receive combination code information on the new service interface through the first window.

Wherein, the same service interface corresponds to a plurality of service implementations;

at this time, the apparatus may further include:

and the list display unit is used for providing a defined service interface list through the second window and providing service implementation list information corresponding to a specified service interface after one specified service interface is selected.

A fourth operation option providing unit, configured to provide a fourth operation option for constructing, deploying and publishing the received service code;

the code issuing unit is specifically configured to, according to the operation request received through the fourth operation option, construct and deploy the service code and then issue the service code.

The code release unit is specifically configured to:

after the service code is constructed, generating an instruction packet, deploying the instruction packet to a specified server, and determining a service address for storing the service code;

and issuing the service code according to the service address information corresponding to the service code.

Wherein the server comprises a distributed cluster of servers; the service code is deployed to a plurality of servers in the distributed server cluster.

In addition, the apparatus may further include:

and the version updating unit is used for providing a fifth operation option for performing version updating on the released service code.

In addition, an embodiment of the present application further provides an electronic device, including:

one or more processors; and

Fig. 5 illustrates an architecture of a computer system, which may specifically include a processor 510, a video display adapter 511, a disk drive 512, an input/output interface 513, a network interface 514, and a memory 520. The processor 510, the video display adapter 511, the disk drive 512, the input/output interface 513, the network interface 514, and the memory 520 may be communicatively connected by a communication bus 530.

The processor 510 may be implemented by a general-purpose CPU (Central Processing Unit), a microprocessor, an Application Specific Integrated Circuit (ASIC), or one or more Integrated circuits, and is configured to execute related programs to implement the technical solution provided in the present Application.

The Memory 520 may be implemented in the form of a ROM (Read Only Memory), a RAM (Random access Memory), a static storage device, a dynamic storage device, or the like. The memory 520 may store an operating system 521 for controlling the operation of the electronic device 500, a Basic Input Output System (BIOS) for controlling low-level operations of the electronic device 500. In addition, a web browser 523, a data storage management system 524, and a code development processing system 525, among others, may also be stored. The code development processing system 525 may be an application program that implements the operations of the foregoing steps in this embodiment of the application. In summary, when the technical solution provided in the present application is implemented by software or firmware, the relevant program codes are stored in the memory 520 and called to be executed by the processor 510.

The input/output interface 513 is used for connecting an input/output module to realize information input and output. The i/o module may be configured as a component in a device (not shown) or may be external to the device to provide a corresponding function. The input devices may include a keyboard, a mouse, a touch screen, a microphone, various sensors, etc., and the output devices may include a display, a speaker, a vibrator, an indicator light, etc.

The network interface 514 is used for connecting a communication module (not shown in the figure) to realize communication interaction between the device and other devices. The communication module can realize communication in a wired mode (such as USB, network cable and the like) and also can realize communication in a wireless mode (such as mobile network, WIFI, Bluetooth and the like).

Bus 530 includes a path that transfers information between the various components of the device, such as processor 510, video display adapter 511, disk drive 512, input/output interface 513, network interface 514, and memory 520.

In addition, the electronic device 500 may also obtain information of specific pickup conditions from the virtual resource object pickup condition information database 541 for performing condition judgment, and the like.

It should be noted that although the above-mentioned devices only show the processor 510, the video display adapter 511, the disk drive 512, the input/output interface 513, the network interface 514, the memory 520, the bus 530, etc., in a specific implementation, the device may also include other components necessary for normal operation. Furthermore, it will be understood by those skilled in the art that the apparatus described above may also include only the components necessary to implement the solution of the present application, and not necessarily all of the components shown in the figures.

From the above description of the embodiments, it is clear to those skilled in the art that the present application can be implemented by software plus necessary general hardware platform. Based on such understanding, the technical solutions of the present application may be essentially or partially implemented in the form of a software product, which may be stored in a storage medium, such as a ROM/RAM, a magnetic disk, an optical disk, etc., and includes several instructions for enabling a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the method according to the embodiments or some parts of the embodiments of the present application.

The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, the system or system embodiments are substantially similar to the method embodiments and therefore are described in a relatively simple manner, and reference may be made to some of the descriptions of the method embodiments for related points. The above-described system and system embodiments are only illustrative, wherein the units described as separate parts may or may not be physically separate, and the parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of the present embodiment. One of ordinary skill in the art can understand and implement it without inventive effort.

The service code development processing method and device provided by the present application are introduced in detail, and a specific example is applied in the text to explain the principle and the implementation of the present application, and the description of the above embodiment is only used to help understand the method and the core idea of the present application; meanwhile, for a person skilled in the art, according to the idea of the present application, the specific embodiments and the application range may be changed. In view of the above, the description should not be taken as limiting the application.

Claims

1. A service code development processing method is characterized in that a plug-in is provided for a development tool, and the following processing is executed through the plug-in:

2. The method of claim 1,

after receiving an operation request through the first operation option, the method further comprises:

and providing an initialization code through the first window according to the template corresponding to the service code type.

3. The method of claim 2,

the initialization code includes all dependency codes except for business logic codes so that code information related to business logic is received only through the first window.

4. The method of claim 1, wherein:

the first operational option includes: a first operation option for defining a new service interface, so as to receive a service definition code related to the service interface through the first window, wherein the service definition code comprises codes for describing the functions, the functions and the participation of the service interface.

5. The method of claim 4, further comprising:

testing whether the newly defined service interface is successfully defined to obtain a test result, and providing a second operation option for checking whether the service interface is successfully defined;

and after receiving an operation request through the second operation option, providing the test result.

6. The method of claim 1, wherein:

the first operational option includes: a first operation option for providing a service implementation for a specified service interface to receive implementation code information regarding the service implementation through the first window.

7. The method of claim 6, further comprising:

providing a third operation option for viewing service interface information to which the service implementation belongs;

and after receiving an operation request through the third operation option, providing the service interface information to which the service implementation belongs.

8. The method of claim 1, wherein:

the first operational option includes: a first operation option for combining at least two existing service interfaces into a new service interface by defining a call relationship between the at least two existing service interfaces, so as to receive combination code information on the new service interface through the first window.

9. The method of claim 1, wherein:

the same service interface corresponds to a plurality of service implementations;

the method further comprises the following steps:

and providing a defined service interface list through the second window, and providing service implementation list information corresponding to a specified service interface after a specified service interface is selected.

10. The method of claim 1, further comprising:

providing a fourth operation option for constructing, deploying and publishing the received service code;

and constructing and deploying the service code according to the operation request received through the fourth operation option, and then issuing the service code.

11. The method of claim 10, wherein:

the service code is constructed, deployed and released, and the method comprises the following steps:

12. The method of claim 11, wherein:

the server comprises a distributed server cluster;

the service code is deployed to a plurality of servers in the distributed server cluster.

13. The method of claim 1, further comprising:

providing a fifth operation option for version updating the released service code, so as to update the version of the service code.

14. A service code development processing apparatus, wherein the apparatus is a plug-in for a preset development tool, comprising:

15. An electronic device, comprising:

one or more processors; and