How to deploy a web service on the Internet. Web services. Providing functionality through Web services

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 get 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:
  1. SOAP. Before calling a remote procedure, you need to describe this call in XML file e 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.
  2. 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, throughout the first 200 pages there is detailed description 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 you not only to call remote methods, but also to simply send 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:
  1. Describe the interface of our web service
  2. Implement this interface
  3. Launch our web service
  4. Write a client and remotely call the desired web service method
The web service can be launched different ways: either describe a class with a main method and run 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 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 full name 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.

Web services in 1C

This article will discuss the integration of 1C with existing web services and the use of 1C itself as a web service.

In this case, web services will be understood as systems that operate on the Internet and provide interaction with them not only via SOAP (which is precisely a web service), but also in other ways, including regular HTTP(S) requests.


Risks of using 1C web services

The 1C81 platform introduced the implementation of web services.

But their use is fraught with risks:

  1. 1C8 does not work well over HTTPS, there are no diagnostic tools, so it is sometimes impossible to understand why, even if there is a certificate, the service does not want to work over HTTPS. The solution is to implement web services via CURL or raise an HTTPS tunnel.
  2. 1C8 adheres to its rules for validating WSDL schemas. Sometimes, for inexplicable reasons, the WSDL schema does not want to be loaded into the WS link. You can find out the reason only on the partner forum from one specialist. There are no WSDL schema diagnostic tools, not even the reason or line at which the schema loading is interrupted is indicated.

Rules for building sales services

The client is issued a sales document (receipt) only if the service transaction is successful. Otherwise, a situation is possible when the client receives a check and is confident that he received a service, but in fact he did not.

Using external SOAP services

SOAP web services use WSDL schemas and XDTO objects to represent data.

Loading WSDL

In order to use an external service, you need to download its WSDL schema.

Checking the validity of the WSDL schema

Sometimes the WSDL schema does not load into 1C. You can check the validity (correctness) of the schema using any WSDL schema validator, for example http://www.validwsdl.com/.

You need to upload the scheme to some http site (you can use ftp) and indicate the address of the file in which the scheme is loaded:

Features of loading WSDL in 1C

The peculiarity of loading WSDL in 1C is that valid schemas may not be loaded. There is no built-in validator, so you have to look for an error using destructive analysis, successively reducing the number of elements in the circuit. You can, for example, delete the web service description.

Processing for testing a running external web service

To test a working external web service, use the “Test ArbitraryWebService.epf” processing from the package for this article.

Testing can be used using the example of the Morpher service, which declines names (service address http://www.morpher.ru/WebServices/Morpher.asmx?WSDL):

In this way you can test any service that has simple entry points containing parameters simple types: number, date, string.

During processing, you can also specify the login and password that are required to authorize access to the web service.

Standard tools for debugging services

For debugging, you can use the SoapUI program, which can send an arbitrary request to a web service and receive a response from it.

SOAP and HTTPS

Unfortunately, SOAP in 1C behaves quite capriciously when working via the HTTPS protocol; practice shows that it is impossible to achieve an HTTPS connection, although the possibility is declared in the platform. The lack of diagnostic and debugging tools to find out the reasons why the connection is not established is taking its toll. Therefore, it is convenient to use SOAP via CURL.

The built-in mechanism for using HTTPS means that all certificates must be published in shared file pem in the 1C program directory.

Using 1C as a service

Rules for developing a service based on 1C

Operation Hello

The rule of good form is to create an operation in the service that informs that the service is available. This makes life easier for integrators; it will be easier for them to check whether communication with the service is established.

For example, you can use the Hello operation without parameters, which simply returns the Boolean value True.

Publishing a web service

The procedure is well described in the documentation: file:///C:/Program%20Files/1cv81/AddDoc/RU/V8AddDoc81.htm#_Toc176167634:

The task of publishing Web services comes down to placing the *.1cws configuration files of Web services in the appropriate directory of the web server with the appropriate settings for the web server. In order to publish Web services, you should execute the menu command “Administration | Publishing Web services."

As a result of executing this command, the Web services publishing window will open.

The Web services publishing window contains the path to the web server and two lists:

  • “Web services” - list of configuration web services;
  • “Publication” - a list of Web services published on the specified web server.

Using the "Connection..." button, you should specify the web server on which you want to publish Web services.

The web server path selection window allows you to specify the path in two ways:

  • on the “Files” tab - this method is used when publishing is performed on the same computer on which the web server is installed. The path is a local directory corresponding to the Internet page from which the published Web server will be called;
  • on the “FTP site” tab - this method is used when you need to publish a Web service on a remote computer. To publish, you must specify the FTP connection parameters with remote computer and the directory in which the Web service will be published.

The selected Web service is published using the “Publish” button

To cancel publishing a Web service, use the “Delete” button.

You can publish to a local directory or via FTP. You can also publish to a remote server via a UNC path if the remote server is part of the local network.

After publication, the web service is available at the address “http://localhost/test.1cws” or “http://xxx.ru/test.1cws”, where xxx.ru is the address of the remote server and localhost is the typical address of the local server.

Authorization to the 1C web service

To access the service you need to pass authentication.

Authorization issues are well addressed here: http://www.forum.mista.ru/topic.php?id=341168 and in the documentation file:///c:/Program%20Files/1cv81/AddDoc/RU/V8AddDoc81.htm

Typically, a web service runs under one specific user (usually a specially created one). You can “attach” a 1C user using Windows authentication to the Windows user IUSR_ (disable 1C authorization for the user). Alternatively, you can clear the list of 1C users, then authorization is not required.

If several users are required, then you can create several logins for the web server and bind them to each of them Windows user and accordingly, register access to Windows users in 1C.

In the User and Password properties of the WSProxy object, it is not the 1C login that is used, but the web server user login.

Testing 1C web service

To test 1C as a web service, use the “Test ArbitraryWebService.epf” processing, as described in the “Testing a running external web service” section.

The 1cws file is a WSDL description of the 1C web service.

Using services in Retail

Typically, retail services are used to provide various services to the population - accepting payments, repaying loans, money transfers, purchasing software and so on.

In this case, a receipt is generated in 1C for the service provided, in which the transaction parameters are saved. After which this check is printed to the client with detailed information about the service provided. It is possible to print a preliminary check so that the client confirms the data entered from his words with his signature.

The service can be integrated in different ways into a retail program written in the 1C language (UT, Retail and others):

  1. Processing or code can be written in 1C language, which performs all the work with the service.
  2. A program can be used that works with the service, and in 1C only transmits information for punching checks.

Organization of service data in 1C

To store transaction information in a receipt, you need to create an additional tabular part“Complex sales” with details:

  • Nomenclature - link to the nomenclature of the check.
  • Parameter - link to the “Complex sales: Parameters” reference book.
  • Value - the value of the parameter, a complex type. The string representation must be quite long (1024 characters) to accommodate the check text.

The “Complex Sales: Parameters” directory contains a list of transaction parameters.

It is more profitable to use the tabular part than a set of details, because a transaction may have a lot of them, and in other checks not related to the service, these details will not be used and will take up extra space. In addition, such a solution is universal for any service and does not require data restructuring after the implementation of a new service.

The seller is given a separate bookmark (or a printed form, so as not to change the configuration), in which he can view the transaction details plate for the check.

Using processing in 1C language

Let's look at the example of the Paym conditional service for the “Retail” configuration.

  1. Let’s create a predefined element of the nomenclature directory “Paym” in 1C. In 1C:Enterprise mode, after updating the configuration, it needs to be assigned the product type “Service”.
  2. In the procedure “Add item to table. part" of the "Sales Registration" form module, we call processing of work with the service, written in the 1C language. If the payment is successful, we record and post the check:
If (Nomenclature = Directories.Nomenclature.Paym) AND (Type of Transfer Transaction. Types of Operations Check KKM. Return) Then Payment Processing = Functions. Give External Processing ("Paym"); PaymentForm = PaymentProcessing.GetForm(); Result = PaymentForm.OpenModal(); If Result = Undefined Then Return; endIf; ThisObject.Write(DocumentWriteMode.Post); endIf;
  1. Processing should print the preliminary receipt (if required), fill out the tabular part of complex sales and prepare the check printing text in the predefined “PaymCheckText” attribute.
  2. In the “Post and print a receipt” procedure of the receipt module, we replace the name of the product with the one saved in the details for the receipt. The text is replaced only for sales; for returns, simply the name of the service is printed, as usual.
OtherwiseIf Type of Transfer Transaction.Types of OperationsCheck KKM.Return And Selection.NomenclatureLink = Directories.Nomenclature.Paym Then //Osipov PaymMaster ComplexSales Line = ComplexSales.Find(Directories.ComplexSalesParameters.PaymReceiptText, "Properties"); If Complex Sales Line is undefined Then Product.Name = Abbreviated LP(Complex Sales Line. Value); endIf;

A separate question is how to ensure the completion of the transaction. Those. If the transaction took place in the service, how to make sure it is not lost in 1C. The most optimal way is to reconcile the registers. But this is a subject for separate consideration.

Using programs that integrate with 1C

XDTO

XDTO is often used in web services. Here are the most important tips and recipes for using XDTO in 1C.

XDTO in the 1C platform

XDTO packages, described in the “XDTO objects” branch of the configuration, are available for creating types and objects in the global factory XDTO Factory. This is not immediately obvious.

Some types in the schema do not have a name; to get them, you need to go through the type hierarchy.

The example described a System list containing XDTO structures. To create the structure itself, you had to get its type like this:

Type = Factory.Type("urn:my.ru:MasterData:Business", "Business").Properties.Get("System").Type;

Common problems with XDTO

Different XSD Schema Formats

In some formats, tags are called xs:, in some xsd:, but 1C safely understands both formats. Once there was a situation where XSD was imported into 1C normally without errors, but did not create a single package. The reason was the absence of an attribute targetNamespace at the tag, accordingly, 1C did not know which package to place the diagram in, but it did not generate errors.

Service support

Considering that the service is a combination of two systems - 1C and external, errors can occur in both systems, which reduces the overall reliability of operation.

To make it easier to understand the reasons for service failures, it is recommended to use a set of measures.

Logging requests

Links

  • XDTO
    • Good description of XDTO http://pro1c.org.ua/index.php?showtopic=214
  • Free interesting web services:
    • Aeroflot - information on flight schedules
    • Morpher - declension of names http://www.morpher.ru/WebServices/Morpher.aspx
  • Unassembled:
    • Installing and using Web services
      • v8: how to change apache configuration file?
      • v8: continuation of the topic with web services - I can’t connect the web service
      • v8: I continue to crawl through web services - I can’t create a proxy...
      • Knowledge Book: v8: Using external web services in 1C:Enterprise 8;

Web services is one of the platform mechanisms used for integration with other information systems. It is a means of supporting SOA (Service-Oriented Architecture), a service-oriented architecture that is a modern standard for integrating applications and information systems.

A significant advantage of service-oriented architecture is that it allows you to develop the enterprise infrastructure in a uniform way, without destroying existing solutions. Its use allows you to minimize costs by integrating heterogeneous and legacy systems into the modern enterprise landscape. It allows you to implement loosely coupled software components in order to maximize their reuse.

Service-oriented architecture is being intensively developed and supported by major vendors. It is built on the basis of services, autonomous or managed externally. The preferred way to implement them is through web services. They are platform independent, standalone, and supported everywhere.

Application solution 1C:Enterprise 8 can be both a provider of web services and a consumer of web services published by other providers.

Systems using arbitrary hardware and software platforms. Web services technology is platform independent.


Technical implementation of web services

If the application solution is a web service provider, then in both the file and client-server modes of operation, the interaction between the application solution and web service consumers is carried out through the web server, using the web server extension module.

In this case, when a consumer accesses the web service of an application solution, the web service module is executed. This module is contained in the configuration and contains procedures that are executed when calling certain web service operations.

In the case of a client-server version of work, this module will be executed in a cluster. In the case of the file version of work - in the web server extension module.

If the application solution is a consumer of a third-party web service provider, then in this case the interaction between the application solution and the web service provider is carried out

Data exchange is usually organized by uploading a file from one program and loading it into another. Some programmers provide third party programs access to SQL database 1C (which seems to be strongly not recommended).

The term “data exchange” does not always suit the task; sometimes it is more correct to say data provision. For example, an external program needs to identify whether such a client exists in 1C and its balance.

Providing access to 1C data is incorrect for data security reasons. What is needed is rather a verification mechanism by name and password with further balance return.

This approach is called a service approach, when the program provides not data, but a service that allows you to identify the client and find out his balance.

How it works?

Functions from outside are called (launched) by a request using the SOAP protocol.

Used to pass parameters and results. To work with web services, you must have a basic understanding of .

Web services 1C

1C Web service is a method by which you can allow some 1C functions to be launched outside the 1C database, including from other programs or other 1C databases.

This is better than providing direct access to 1C data, since when calling a method (function) of a 1C web service, the external program does not have access to the data. The function in 1C language independently determines the right external program receive a specific amount of data based on the passed parameters (for example, username and password).

In many cases, you can not create your own XDTO package, but use the default one by selecting the package www.sample-package.org from the list

1C web service methods

After this, you need to add a list of functions (methods of the 1C web service) that will be provided externally. It is better to call them in English. A function can have parameters.

Basic types to use:

  • string – string
  • int or integer – whole number
  • real – fractional number
  • date – date.

For each added function of the 1C web service, you need to create it in the properties, just like we did in, and so on.

It is this 1C function that will be executed when calling the 1C web service method. Do not forget that it will be performed on the 1C server. The file mode of working with 1C web services is not recommended.

A function usually returns some data. Typically the type is string and an XML string is returned.

An XML string can be generated using 1C language objects for , or you can simply create a text string in which the XML text is stored.

Publishing a 1C web service

As we said earlier, other programs must “know” that the 1C web service exists, has such a list of methods, and so on.

The description should be on the website. To do this you need:

  • Have a website
  • In the properties of the 1C web service, specify the file name with the extension 1cws, which is a link to the WSDL description
  • Upload this file to the website in the configurator using the Administration/Publish on web server menu item.

The browser should display some kind of XML file (an example of a WSDL file here http://ru.wikipedia.org/wiki/WSDL), and not an error, not a blank page, and not slurred text in any encoding.

After successful publication, the 1C web service can be used. To do this in another program you need to use this internet address for links to the 1C web service.

For example, Visual Studio allows for any language (C++, C#, Visual Basic) – include a 1C web service in the project according to its WSDL description and generate a class for using the 1C web service.

Fortunately, there are no restrictions on working with web services.

Adding a Web Service to Metadata

Open the configuration tree, branch Are common, Further Web services, add a new web service (I’ll call it my_ws) and fill in the properties as shown in the figure.

A few clarifications need to be made about the properties of web services.

  • XDTO Packages- This field specifies a list of XDTO packages whose types can be used in the value that is returned as a result of web service operations.
  • Namespace URI is a string that specifies the namespace URI for of this web service. Any web service can be uniquely identified by the combination of its name and namespace. It is necessary to clearly understand that this property has nothing to do with the physical address of the web server, or with the organization’s website, etc. It's just a virtual address. Therefore, you need to assign a clear name that can tell, for example, about the area of ​​​​location and application of the web service. In particular, the abbreviation may be present typical configuration to which the web service belongs.

Web Service Operations

To ensure the functioning of a web service, it is necessary to create operations for it that will perform certain actions and, if necessary, return the necessary data.

As an example, let's create an operation for our web service that will return the classic phrase “Hello world!” Let's call her Hello:

Let's create a function in the web service module Hello World(), the link to which will be inserted into the corresponding property of the operation.

HelloWorld() Function Return "Hello world!" ; EndFunction

But this operation has one drawback. You cannot transfer original data to it. For these purposes, the operations of web services use their subordinate objects - Options.

Let's add one more operation - HelloUsr, and create a parameter for it Name.

This operation will return a greeting to the user by calling the following function:

Function HelloUser(UserName) Return "Hello, " + UserName + "!" ; EndFunction

Publishing a Web Service

Now we are ready to publish the web service. To do this, you need to log into the configurator with administrator rights. Click on the 1C shortcut right click and select the appropriate menu item:

Select from the menu Administration —> Publishing to a web server

In the window that opens, enter the name of the publication and check the box Publish Web Services and also mark the web service we created:

WS links

To work with web services, the following 1C object is used: WS-link. It is a WSDL description of a web service obtained by importing from the source on which the web service is located. That is, first of all, we need to know the address at which we can get the WSDL description of the web service. In relation to our example, in accordance with the settings that we made during the process of creating and publishing the web service, this address will look like this:

Http://localhost/professia1c/ws/my_ws.1cws?wsdl

Let's look at what parts this address consists of.

  • http://localhost/- This address indicates the physical location of the web server. Since I have it on the local machine, it’s localhost, but in practice this is either the server’s IP address or its name
  • professia1c is the name of the publication. We entered it into the field Name in the dialog when the web service was published
  • ws- a sign that we are accessing a web service
  • my_ws.1cws— the name of the publication file that we specified in the properties when creating the web service
  • ?wsdl- a parameter that indicates that we need to get a WSDL description

After publishing a web service, to ensure that it was published successfully, you can enter the address of its WSDL description in address bar browser. In this case, we should receive an XML file in the browser window with approximately the following content:

  1. Using a dynamic ws link.
  2. Creating a static ws link.

Let's look at each of these methods.

Dynamic WS links

&OnServer Procedure ConnectOnServer() WSOdefinition = New WSDefinition( "http://localhost/professia1c/ws/my_ws.1cws?wsdl", "Sidorov" , "" ) ; WSProxy = New WSProxy(WSOdefinition, "http://www.site/" , "my_ws" , "my_wsSoap" ) ; VSProxy. User = "Sidorov" ; VSProxy. Password = "" ; TextVS = VSProxy. HelloUsr("Vasya" ) ; Message = New MessageToUser; Message. Text = TextVS; Message. To report() ; End of Procedure

As you might guess, the result of this procedure will be the text in the message window “Hello, Vasya!”

Static WS links

Instead of programmatically creating an object WS Definitions we can directly create a WS-link metadata object in the configuration tree. During the creation process, a window will be displayed asking you to specify the address of the WSDL definition to import it:

We can then refer directly to this WS reference in code. And the procedure for accessing the web service will take the following form:

&OnServer Procedure ConnectThroughLinkOnServer() VSProxy = WSLinks. WSlink_my_ws. CreateWSProxy("http://www.site/" , "my_ws" , "my_wsSoap" ) ; VSProxy. User = "Sidorov" ; VSProxy. Password = "" ; TextVS = VSProxy. HelloUsr("Vasya" ) ; Message = New MessageToUser; Message. Text = TextVS; Message. To report() ; End of Procedure