What is a web service? Web services. How many different types of web services are there?

Today WEB services are used almost everywhere - they provide us with information about plane and train flights, exchange rates and weather. It is not surprising that 1C also has the ability to create its own WEB services, allowing it to act as both a supplier and a consumer. This mechanism is built into the 1C:Enterprise 8.3 platform and developers can even add their own objects of the WEB services type to the standard configuration. Their architecture is built on a set of services that allow you to exchange information with other software.

Creating a 1C web service

One of the main advantages of 1C WEB services is the absence of the need to provide direct access to information security data. A correctly configured 1C web service allows other applications to use functions from the outside. In such cases, the function itself should determine the right to use data according to the specified parameters according to the rules prescribed by the developer.

How to create a web service in 1C?

In order for a certain function of the 1C system to become available to external software, it is necessary to perform the following algorithm of actions:

Go to the configuration and add a WEB service object in a certain branch of the tree;
Describe all the operations that our functionality can perform. The description of functions is carried out in the module in the built-in 1C language;
Add a description of the parameters of the web service functions. Please note that the data types are described taking into account the existing types of the XDTO mechanism introduced in the platform version 8.1;
Publish the created WEB service on the server. The mechanism built into the 1C platform supports the following standards:

SSL/TLS
WS-I BP

An example of creating a simple WEB service

To most clearly demonstrate the operation of the WEB services mechanism, let's create an example - a functionality that determines the length of the entered string. The software will pass a string as a request parameter, and the function described in 1C will return the number of characters. When creating, you need to remember that publishing this mechanism will make it possible for various software to access it. Since not every software is capable of accepting the Cyrillic alphabet, we will name configuration objects using Latin characters.

Open the configurator, find the “WEB services” branch in the tree and add a new service “wa_LengthString”. You also need to add a new operation on the “Operations” tab. Let's call it “CalcLengthString”, specify the return value type in the properties - int or integer and create the “InputString” parameter inside it. We leave the value type as string.

Now you need to register the action of the CalcLengthString function in the WEB service module. To do this, open the properties of the created function and click the button in the form of a magnifying glass on the right, next to the “Procedure name” input field. 1C will automatically create a function in our WEB service module and open it so that we can describe the CalcLengthString action. Let's take advantage of this and write the action of the function - determining the length of the input string.

In fact, this completes the creation of a simple WEB service. Now it is necessary to “put” this service into the public domain so that third-party software or other 1C systems can use this functionality.

In order for us to be able to publish the created web service with its functionality, we need to have access to the site. Before we start publishing the service, we need to check the file name in the properties of the created wa_LengthString module. It should be clear, simple and have the extension “1cws”.

Now it's time to publish the WEB service we created on the server. This feature appeared in platform version 8.3 and many companies have already realized the full benefits of this functionality. In order to start publishing, you need to open the “Administration/Publishing on a web server...” form in the configurator.

In the window that opens, we need to configure 1C Web services and fill in certain fields:

Name. Designates the folder on the web server in which the description of our web service will be stored. Be careful about cases, as sometimes servers distinguish between large and small case characters;
Web server. You must select a server from those installed on your computer;
Catalog. You must select the path to the folder where the web server data for setting up the connection is stored. Only Latin letters are used;
Two signs of the Boolean type. The first one will be useful to us if we need to configure access to the configuration via a web client. In order to publish a 1C service, you need to check the second box.

All that remains is to check that the desired WEB service has the checkbox checked in the first column and click on “Publish”.

Since this mechanism is still quite new, you may encounter an error like “An error occurred while performing a file operation...”. In this case, you just need to click “Publish” again. In most cases, this will help and you will see a message indicating that the web service has been published.

Ru//ws/.1cws?wsdl

In response to such an address request, the browser must display the structure of the XML file. If you see a blank page, an error, or strange characters (encoding problems), then you need to check all the steps again. It is also a good idea to make sure that the server is configured correctly and you have access to it. After successful publication, the 1C WEB service will be able to be used by third-party applications.

The topic title is really a question, because... I myself don’t know what it is and for the first time I will try to work with it within the framework of this article. The only thing I can guarantee is that the code presented below will work, but my phrases will only be assumptions and guesses about how I myself understand all this. So, let's go...

Introduction

We need to start with why the concept of web services was created. By the time this concept appeared in the world, technologies already existed that allowed applications to interact at a distance, where one program could call some method in another program, which could be launched on a computer located in another city or even country. All this is abbreviated as RPC (Remote Procedure Calling). Examples include CORBA technologies, and for Java - RMI (Remote Method Invoking). And everything seems to be good in them, especially in CORBA, because... You can work with it in any programming language, but something was still missing. I believe that the disadvantage of CORBA is that it works through some of its own network protocols instead of simple HTTP, which will fit through any firewall. The idea of the web service was to create an RPC that would be inserted into HTTP packets. Thus began the development of the standard. What are the basic concepts of this standard:

SOAP. Before calling a remote procedure, you need to describe this call in an XML file in SOAP format. SOAP is simply one of the many XML markups that are used in web services. Everything we want to send somewhere via HTTP is first converted into an XML SOAP description, then stuffed into an HTTP packet and sent to another computer on the network via TCP/IP.
WSDL. There is a web service, i.e. a program whose methods can be called remotely. But the standard requires that this program be accompanied by a description that says that “yes, you’re right - this is really a web service and you can call such and such methods from it.” This description is represented by another XML file, which has a different format, namely WSDL. Those. WSDL is just an XML file describing a web service and nothing more.

Why so briefly you ask? Can't you be more specific? It’s probably possible, but to do this you’ll have to turn to books such as T. Mashnin, “Java Web Services.” There, over the first 200 pages, there is a detailed description of each tag of the SOAP and WSDL standards. Is it worth doing? In my opinion, no, because... all this is created automatically in Java, and you only need to write the contents of the methods that are supposed to be called remotely. So, an API such as JAX-RPC appeared in Java. If anyone doesn't know, when they say that Java has such and such an API, it means that there is a package with a set of classes that encapsulate the technology in question. JAX-RPC evolved over time from version to version and eventually became JAX-WS. WS obviously stands for WebService and you might think that this is simply a renaming of RPC as a popular buzzword these days. This is not true, because Now web services have moved away from the original idea and allow not only calling remote methods, but also simply sending document messages in SOAP format. I don’t know why this is needed yet; it’s unlikely that the answer here will be “just in case it’s needed.” I myself would like to learn from more experienced comrades. And lastly, then JAX-RS appeared for so-called RESTful web services, but this is the topic of a separate article. The introduction can end here, because... Next we will learn to work with JAX-WS.

General approach

In web services there is always a client and a server. The server is our web service and is sometimes called the endpoint (as in, the end point where SOAP messages from the client reach). We need to do the following:

Describe the interface of our web service
Implement this interface
Launch our web service
Write a client and remotely call the desired web service method

You can launch a web service in different ways: either describe a class with the main method and launch the web service directly as a server, or deploy it to a server like Tomcat or any other. In the second case, we ourselves do not launch a new server and do not open another port on the computer, but simply tell the Tomcat servlet container that “we have written web service classes here, please publish them so that everyone who contacts you can use our use the web service." Regardless of the method of launching the web service, we will have the same client.

Server

Let's launch IDEA and create a new project Create New Project. Let's indicate the name HelloWebService and press the button Next, then button Finish. In folder src let's create a package ru.javarush.ws. In this package we will create the HelloWebService interface: package ru. javarush. ws; // these are annotations, i.e. a way to mark our classes and methods, // as related to web service technology import javax. jws. WebMethod; import javax. jws. WebService; import javax. jws. soap. SOAPBinding; // we say that our interface will work as a web service@WebService // we say that the web service will be used to call methods@SOAPBinding (style = SOAPBinding. Style. RPC) public interface HelloWebService ( // we say that this method can be called remotely@WebMethod public String getHelloString(String name) ; ) In this code, the WebService and WebMethod classes are so-called annotations and do nothing except mark our interface and its method as a web service. The same applies to the SOAPBinding class. The only difference is that SOAPBinding is an annotation with parameters. In this case, the style parameter is used with a value indicating that the web service will work not through document messages, but as a classic RPC, i.e. to call a method. Let's implement our interface logic and create a HelloWebServiceImpl class in our package. By the way, I note that ending a class with Impl is a convention in Java, according to which the implementation of interfaces is so designated (Impl - from the word implementation, i.e. implementation). This is not a requirement and you are free to name the class whatever you want, but good manners require it: package ru. javarush. ws; // the same annotation as when describing the interface, import javax. jws. WebService; // but here it is used with the endpointInterface parameter, // indicating the full name of the interface class of our web service@WebService(endpointInterface= "ru.javarush.ws.HelloWebService") public class HelloWebServiceImpl implements HelloWebService ( @Override public String getHelloString (String name) ( // just return the greeting return "Hello, " + name + "!" ; ) ) Let's launch our web service as an independent server, i.e. without the participation of any Tomcat and application servers (this is a topic for a separate discussion). To do this, in the project structure in the folder src Let's create a package ru.javarush.endpoint, and in it we will create a HelloWebServicePublisher class with the main method: package ru. javarush. endpoint; // class for running a web server with web services import javax. xml. ws. Endpoint; // class of our web service import ru. javarush. ws. HelloWebServiceImpl; public class HelloWebServicePublisher ( public static void main (String... args) ( // start the web server on port 1986 // and to the address specified in the first argument, // start the web service passed in the second argument Endpoint. publish( "http://localhost:1986/wss/hello", new HelloWebServiceImpl () ) ; ) ) Now let's run this class by clicking Shift+F10. Nothing will appear in the console, but the server is running. You can verify this by typing the line http://localhost:1986/wss/hello?wsdl in your browser. The page that opens, on the one hand, proves that we have a web server (http://) running on port 1986 on our computer (localhost), and, on the other hand, shows a WSDL description of our web service. If you stop the application, the description will become unavailable, as will the web service itself, so we won’t do this, but move on to writing the client.

Client

In the project folder src Let's create a package ru.javarush.client , and in it the HelloWebServiceClient class with the main method: package ru. javarush. client; // needed to get wsdl description and through it // reach the web service itself import java. net. URL; // this exception will occur when working with a URL object import java. net. MalformedURLException; // classes to parse xml with wsdl description // and reach the service tag in it import javax. xml. namespace. QName; import javax. xml. ws. Service; // interface of our web service (we need more) import ru. javarush. ws. HelloWebService; public class HelloWebServiceClient ( public static void main (String args) throws MalformedURLException ( // create a link to wsdl description URL url = new URL ( "http://localhost:1986/wss/hello?wsdl") ; // We look at the parameters of the next constructor in the very first tag of the WSDL description - definitions // look at the 1st argument in the targetNamespace attribute // look at the 2nd argument in the name attribute QName qname = new QName ("http://ws.site/" , "HelloWebServiceImplService" ) ; // Now we can reach the service tag in the wsdl description, Service service = Service. create (url, qname) ; // and then up to the port tag nested in it, so that // get a link to a web service object remote from us HelloWebService hello = service. getPort(HelloWebService.class); // Hooray! You can now call the remote method System. out. println (hello. getHelloString ( "JavaRush" ) ) ; ) ) I gave maximum comments on the code in the listing. I have nothing to add, so let’s run (Shift+F10). We should see the text in the console: Hello, JavaRush! If you didn’t see it, then you probably forgot to start the web service.

Conclusion

This topic provided a brief excursion into web services. Once again, I will say that much of what I wrote is my guess as to how it works, and therefore you should not trust me too much. I would be grateful if knowledgeable people correct me, because then I will learn something. UPD.

Annotation: Areas of use. Advantages. Features of developing web services for the .NET platform. Description and discovery of a web service

What is XML Web Service?

As information technology developed, different approaches to writing programs arose: modular programming, event-driven programming, component-oriented programming and design. The logical continuation of these approaches was service-oriented software development.

The use of service-oriented approaches allows us to talk about reuse at the macro level (service level), as opposed to the micro level (object level). The service-oriented approach uses simple and generally accepted standards, which allows a wide variety of applications to share each other's functionality. Services can be written using a variety of programming languages, on various platforms. In addition, services can be deployed separately or as part of a software package anywhere in the world and will thus provide access to their functionality over the network.

Let's call service resource that implements a business function and has the following properties:

is reusable;
defined by one or more explicit technology-independent interfaces;
is loosely coupled to other similar resources and can be invoked through communication protocols that allow resources to interact with each other.

A special case of a service is an XML web service.

XML Web service is a special type of web application that:

deployed on a web server;
publishes web methods that can be called by external clients;
waits for the receipt of HTTP requests, which are commands for calling web methods;
executes web methods and returns results.

Unlike a traditional web application, a web service does not have a user interface. Instead, it has a programming interface, that is, the web service exposes functions (web methods) that can be called remotely (for example, over the Internet). The web service is not intended to serve end users. Its job is to provide services to other applications, be they web applications, GUI applications, or console applications.

A Web service can provide real-time information on stock prices, check credit cards, or report the weather forecast. Web services are as diverse as regular applications.

Web services are not the property of a specific company. It is an industry standard based on open protocols (SOAP, HTTP, etc.). Web services are deployed on various platforms (including servers running Windows or UNIX). Web services can be developed using many development tools (from a text editor to the Microsoft Visual Studio family).

Methods of most web services are called by HTTP requests containing SOAP messages SOAP is an XML language (XML vocabulary) for calling remote procedures over HTTP and other protocols (full description of SOAP http://www.w3.org/TR/SOAP) .

Place of web services among other remote calling technologies

There are quite a few remote invocation protocols and technologies: Microsoft Distributed Component Object Model (DCOM), the Object Management Group's Common Object Request Broker Architecture (CORBA), Sun's Remote Method Invocation (RMI), . NET Remoting, XML Web Services.

All of these component-based technologies (DCOM, CORBA, and RMI) have been used successfully in Intranet applications for many years. They provide a reliable, scalable architecture. However, there are two serious problems with using these technologies on the Internet. Firstly, they do not interact well with each other. All technologies operate on objects, but differ significantly in details: lifecycle management, constructor support, and the degree of inheritance support. The second, more important aspect is that the focus on RPC interactions leads to the construction of tightly coupled systems based on explicit calls to object methods.

In contrast to these technologies, XML Web Services and. NET Remoting are fully implemented object-oriented approach for web programming.

XML Web Service- a component that provides Internet clients with a set of API functions or web methods. XML is included in the name because web services and their clients use it to exchange data. Web services are based on open standards such as HTTP, XML (Extensible Markup Language), SOAP (Simple Object Access Protocol - an Intenet standard that describes how applications can interact, that is, call each other's methods, using HTTP and other protocols ). The main task of web services is to ensure inter-program interaction. Many work on UNIX servers and are accessed by Windows clients. Data sent to web services is serialized in XML and sent in SOAP packets. Metadata about the content of such messages is stored in the web service WSDL contract and XSD schemas. The main advantage of this approach is the readability of metadata. The developer can easily view the entire description of the web service and even create his own module that parses SOAP packets.

.NET Remoting provides infrastructure for distributed objects. It is much more complex than a simple message-passing web services architecture. . NET Remoting includes parameter passing by reference and value, callbacks, multiple object activation, and lifecycle management policies. To use these features, the client application must be proficient in all technologies. Data c. NET Remoting are transmitted in binary or SOAP format. However, in any case, metadata about the structure of the transmitted information is contained in the common language execution environment. Without a common language runtime (CLR), the client application will not be able to parse language-specific ones. NET Remoting SOAP headers. That is. NET Remoting imposes significantly higher requirements compared to web services.

Development of web services on the .NET platform

There are many ways to write web services. They can be developed manually or using SOAP tools provided by Microsoft, IBM, etc. Writing web services using Microsoft. NET has two advantages:

The .NET Framework greatly simplifies the development process by providing a class library and automating individual development stages;
Web services written with the .NET Framework are managed applications. That is, such applications do not have problems with memory leaks, incorrectly initialized pointers, and other typical programming problems.

Creation

Let's develop a simple AdditionService web service that adds two numbers. It will have only one Add method, which takes two integers as a parameter and also returns an integer. AdditionService demonstrates several important principles of programming web services using the Microsoft .NET Framework.

Web services are implemented as ASMX files. ASMX is a special filename extension registered to ASP .NET (more specifically, the ASP.NET HTTP Handler) in the main ASP .NET Machine.config configuration file.
ASMX files begin with the @WebService directive. This directive must contain at least the Class attribute, which specifies the class of which the web service consists.
Web service classes can have optional WebService attributes. In this example, this attribute specifies the web service name and description that is displayed on the HTML page when the user calls AdditionService.asmx in the browser.
Web methods are declared by assigning the WebMethod attribute to the public methods of the Web service class. For helper methods that are used internally but are not available to external clients, this attribute is simply not specified.
HTTP, XML and SOAP are "invisible". The .NET Framework handles XML data and SOAP messages.

AdditionService.asmx<%@ WebService language="C#" Class="AddService" %>using System using System.Web.Services class AddService ( public int Add (int a, int b) ( return a + b ) )

Despite its small size, AdditionService.asmx is a full-fledged web service if installed on a web server with ASP.NET. Its methods are called using SOAP, HTTP GET and HTTP POST, and it can return results as SOAP responses or as simple XML wrappers.

Using background code, web service classes can be moved from asmx files into separate files.

Web services support the use complex data types as input or output parameters. Complex data types are supported because XML allows most data types to be easily serialized. However, when automatically testing a web service, ASP .NET does not generate test pages for methods that accept complex data types. This happens because you cannot pass complex data types to a web method using HTTP GET and POST.

Web services allow you to call their methods asynchronously. An asynchronous call returns control immediately, regardless of how long it takes the web service to process the call. Asynchronous calls are useful when processing a call takes a significant amount of time. The application makes the call, then continues running without waiting for the result of the call, and later receives the results of the asynchronous call. The result is obtained by calling the web method again at a time convenient for the application or by subscribing to a notification about the end of processing the call by the web service (delegate mechanism).

Web services can be created using tools such as Microsoft Visual Studio 2005. To create web services, there is a separate project type ASP .NET Web Service. Visual Studio generates an asmx file, a file with background code to describe the web service classes, a web service configuration file, etc. When the project is launched for execution, the service classes are compiled and the asmx file is opened in the browser window.

Description of web services using contracts

In order for other developers to use AdditionService, they need to know what methods it provides, what protocols it supports, method signatures, and the web service address (URL). All this and other information can be described in WSDL (Web Service Description language).

Web service discovery

How do other developers know about the existence of AdditionService?

Firstly, using DISCO (short for the word discovery) - a file-based mechanism for searching local web services, that is, a mechanism for obtaining a list of available web services from DISCO files located on web servers. In addition, DISCO files contain records of the location of the WSDL contracts of available services. A DISCO file is an XML file with records.

It is also possible to use VSDISCO files, which are similar to DISCO files, but their contents are the result of a dynamic search for web services in the specified directories and all subdirectories. ASP .NET maps the .vsdisco filename extension to an HTTP handler, which searches the given directory and its subdirectories for asmx and disco and returns a dynamically generated DISCO document. For security reasons, dynamic search is disabled in some versions of the .NET Framework, but you can enable it by editing the entries in the Machine.config file.

How do you search for web services on the global network? To search for web services on the global network, Microsoft, IBM and Ariba jointly developed UDDI (Universal Description Discovery and Integration) - a specification for building distributed databases that allows you to search for web services. UDDI is supported by hundreds of companies. UDDI sites are themselves web services. Anyone can publish their UDDI-based registry. Most developers never use the UDDI API directly. Instead, UDDI registries are accessed by development tools. They also generate wrapper classes for discovered and selected web services.

Results

An XML Web service is a software component that provides functionality that can be used by a variety of systems that support standards such as XML and HTTP. Web service clients can be both local and remote applications. Web services allow you to create structures that make it easier to integrate different systems based on simple, generally accepted standards.

We looked at the general concepts of using the mechanism « Web-services". Let's refresh some knowledge.

Web services are used to exchange data between a server and a client; The XML format is used to “package” data for the purpose of mutual understanding between both participants in communication.

CHAPTERI

EXAMPLE OF IMPLEMENTATIONWEB- SERVICE IN THE 1C:ENTERPRISE SYSTEM

TASK: It is necessary to create a web service, by accessing which clients can determine all the necessary information on their applications.

The task is a demonstration and serves only as an example for understanding and teaching the mechanismweb-services.

SOLUTION:

Step 1. Let's create a new information base without configuration to develop a new configuration.

Step 2. Let's add several new objects to the configuration

Directory "Clients";

Document "Application";

Enumeration "Application Statuses".

Step 3. Let's create a new XDTO package.

Why and for what purpose are we creating an XDTO package? More information about using the XDTO mechanism can be found in “Chapter 16. Developer’s Guide” and .

Let us briefly note that the XDTO mechanism is a universal way of presenting data for interaction with various external data sources and software systems.

In our case, an XDTO package is created to describe the return value of the web service.

Let’s expand the “General” branch → “XDTO packages” → Add…

Let's specify the name of the XDTO package " DocumentsData"and its namespace http://localhost/request or http://192.168.1.76/request (to facilitate understanding and the learning process, we indicate the local IP address of the computer where the web server is installed (supported web servers: IIS or Apache)). Each Web service can be uniquely identified by its name and the URI of the namespace to which it belongs.

Our package contains two types of XDTO objects:

1) Сustomer- to transfer data from the “Clients” directory element.

- Name ;

2) Document- to transfer data from the “Application” document

This XDTO object type will contain the following properties:

- Сustomer- Customer type from the namespace http://192.168.1.76/request ; represents a reference to the XDTO object we defined above;

- Status- string type from the namespace http://www.w3.org/2001/XMLSchema ;

- Numder- string type from the namespace http://www.w3.org/2001/XMLSchema.

Step 4. Let's add a new Web service to the configuration

Let’s expand the branch “General” → “Web services” → Add…

For the Web service, we specify the following property values:

Name - DocumentsData

Namespace URI - http://192.168.1.76/request

XDTO Packages - DocumentsDataorhttp://192.168.1.76/request

Publication file name - request.1cws

Step 5. For the created Web service we will define the operation “ GetData»

Operation property values:

Return type - Document (http://192.168.1.76/request)

Possibly empty value - True

Procedure name - GetData.

Step 6 At the operation GetData Let's define the Customer parameter with the following property values:

Value type - type string from the namespace http://www.w3.org/2001/XMLSchema;

Transfer direction - input.

Step 7 Let's open the module of the created Web service and place in it the Get() function, which will be executed when this Web service is called.

Function GetData(Customer) // Get the types of XDTO objects ClientType = FactoryXDTO.Type("http://192.168.1.76/request", "Customer"); RequestType = FactoryXDTO.Type("http://192.168.1.76/request", "Document"); // Get the client ClientLink = Directories. Clients.FindByName(Customer); If Not ValueFilled(ClientRef) Then Return Undefined; endIf; Request = New Request; Request.Text = "SELECT TOP 1 | Application.Link, | REPRESENTATION(Application.Status) AS Status, | Application.Number |FROM | Document.Request AS Application |WHERE | Application.Client = &Client"; Request.SetParameter("Client", ClientLink); RequestResult = Request.Execute(); If QueryResult.Empty() Then Return Undefined; endIf; Selection = Query Result.Select(); Selection.Next(); Document = Selection.Link.GetObject(); // Create an XDTO object of an order Order = FactoryXDTO.Create(OrderType); Application.Numder = Sample.Number; Client = FactoryXDTO.Create(ClientType); Client.Name = ClientLink.Name; Application.Customer = Client; Application.Status = Selection.Status; // Return the request Return Application; EndFunction

Step 8 Let's publish the created Web service on the web server.

Menu item Configurator: “Administration” → “Publishing on a Web server”.

On the “Web Services” tab, set the “Publish Web Services” checkbox and also check the box next to our new Web service.

CHAPTERII

EXAMPLE OF APPEAL TOWEB-TO THE 1C:ENTERPRISE SYSTEM SERVICE FROM A THIRD-PARTY APPLICATION

The main purpose of the Web services mechanism in the 1C:Enterprise system is to transfer the necessary data to third-party applications.

Let's consider an example of developing an application in Delphi calling our web service from the first section of this article.

Step 1. Let's create a new project and place several controls on the form

Text field - used to display information received from the web service;

Two buttons - clearing the text field and accessing the web service;

An input field is a parameter passed to the web service.

Step 2. Importing a WSDL file

As a result, we get a new module request(we defined this name directly in 1C). This module contains all the necessary information on the web service.

Step 3. Let's write a web service call handler

The DocumentDataPortType variable is already defined in the module request

Step 4. Launch the application and run the test.

CHAPTERIII

EXAMPLE OF APPEAL TOWEB-SERVICE IN THE 1C:ENTERPRISE SYSTEM

Step 1. Let's create a new external processing with the name "WEB_Service"

Step 2. Let's define a new form for processing

Step 3. We will indicate several details on the form

Client - type "String"

ClientReturn - type "String"

NumberReturn - type "String"

StatusReturn - type “String”.

We will display the details on the form.

Step 4. Let's add a form command " To get data»

Let's specify the command handler

&OnClient Procedure GetData(Command) GetDataOnServer(Client); End of Procedure Procedure GetDataOnServer(Client) // Create a WS proxy based on the link and perform the Get() operation Definition = New WSDefinitions("http://192.168.1.76/WEB_Service/ws/request.1cws?wsdl"); Proxy = New WSProxy(Definition, "http://192.168.1.76/request", "DocumentsData", "DocumentsDataSoap"); Application Data = Proxy.GetData(Client); If Application Data = Undefined Then ClientReturn = "Undefined"; StatusReturn = "Undefined"; ReturnNumber = "Undefined"; Return; endIf; CustomerReturn = Application Data.Customer.Name; StatusReturn = Application Data.Status; Return Number = Application Data.Numder; End of Procedure

The 1C:Enterprise system can use web services provided by other providers in two ways:

By using static links created in the configuration tree;

"plus": high speed;

"minus": re-importing the WSDL description using the configurator and saving the changed configuration.

By using dynamic links created by built-in language tools

(correspondingly, the “cons” of static ones for dynamic ones are “pros”)

CHAPTERIV

DEBUGGING WEB SERVICES IN THE 1C:ENTERPRISE SYSTEM

For a local web service you need:

Step 1. Place the file on the client where the 1C system runs webservicecfg.xml with the following content

Step 2. To file default. vrd publish configuration add line

Step 3. In the configurator, select the menu item

“Debug” → “Connection” → “Automatic connection” → “Web services on the server”

Step 4. Click on the “OK” button

For the server option, you also need to run the 1c server in debugging mode with the key /debug

The mechanism of Web services of the 1C:Enterprise system is based on the use of metadata objects of the same name, i.e. configuration objects from the “Web services” branch.

1. GENERAL DEFINITIONS

Let's try to give a general definition of the term “Web service”.

Web-service is a network technology that provides cross-program interaction(between different applications) based web standards. Web services make it possible to access from one application to another and at the same time perform certain functions.

A web service is identified by a URI (Uniform Resource Identifier) string - a unified resource identifier (this is a character string that allows you to identify a resource).

The web service has a software interface presented in the format WSDL(Web Services Description Language) - a language for describing web services and accessing them, based on the XML language (specification http://www.w3.org/TR/wsdl). Designed for a unified presentation of the external interfaces of a web service and is used so that another program knows that this program has such a “service” (i.e., the first program on the website publishes information about its services in the WSDL file format).

Other systems interact with the web service by exchanging SOAP (Simple Object Access Protocol) messages - a protocol for exchanging structured messages in a distributed computing environment (specification http://www.w3.org/TR/soap). Like any text protocol, SOAP can be used with any application layer protocol: SMTP, FTP, HTTPS and others, but most often SOAP is used over HTTP.

Figure 1. Web service concept.

SOAP is used to exchange arbitrary messages in XML format and remote procedure calls (RPC).

Thus, XML documents formatted as messages are exchanged between the web service and the application. Web services standards define:

Message format, interface to which the message is sent;

Rules for linking message content to the application implementing the service and vice versa;

Mechanisms for publishing and searching interfaces.

The simplest and most obvious example of using web services is obtaining reference data from public services available on the Internet. For example, Aeroflot provides information about its flights through a Web service, the Bank of Russia provides information about exchange rates, securities, credit institutions - there can be many options.

2. WEB- SERVICES IN THE 1C:ENTERPRISE SYSTEM

The 1C:Enterprise 8 application solution can be:

Web service provider;

In the 1C:Enterprise 8 system, Web services are one of the platform mechanisms used for integration with other information systems and 1C:Enterprise 8 applications.

In other words, the 1C:Enterprise system can export its functionality through Web services. Their definitions are specified in the configuration tree and become available to arbitrary information systems by publishing them on a web server.

The Web services mechanism in the 1C:Enterprise system is a means of supporting Service-Oriented Architecture (SOA) - which means that programs use “services” to exchange data with each other.

In order for the functionality of the 1C:Enterprise system to be available to external consumers of Web services, you need to perform the following steps:

Create the required number of Web services in the configuration;

Creating a Web service consists of:

In adding a Web service configuration object to the metadata tree;

Descriptions of the operations that this Web service can perform;

Description of operation parameters.

The Web service configuration object contains a module in which procedures are created in the built-in language that are executed when certain Web service operations are called. Web service operation parameter types are described using XDTO types and can be either XDTO values or XDTO objects.

The Web service is called as follows:

A suitable connection to the infobase is selected from the connection pool; if there is no required connection, a connection is created;

A new session is created;

The requested Web service method is called.

The Web services mechanism implemented in the 1C:Enterprise system supports the following standards:

WS-I Basic Profile 1.1;

SSL 3.0/TLS 1.0.

3. STUDYINGWEB- SERVICES IN THE 1C:ENTERPRISE SYSTEM