VBscript to help 1C programmer

Recently I received the TOR for developing a simple report with the output of the results in files. Nothing unusual, except for a few points:

1. The result of the report should be sent on schedule with a special utility from a third-party developer.
2. Everything should work in fully automatic mode.
3. Changes to the configuration can not be made

If it were not for point 3, I would certainly have implemented it in a rather common way: I included the report in the configuration, added the report to the application module when a special user logged in with a specific name. Accordingly, before launching a third-party utility, I would configure the launch of 1C from the command line under the account of this special user. But…


Virtually all of the initial implementation of the idea (a simple VBScript that, using OLE Automation, connects the COM object of the 1C application and initiates the execution of an external report) is reflected in the Execute () procedure of the code below. Everything else was written in a rush “to make beautiful” and make life easier for yourself and others: the settings are decorated in a separate block with variables, execution errors are processed and recorded in a log file with an indication of the code, description and source of the error.

On Error Resume Next

Dim ComApp, ExtProc, Path, Dest, LogName, ExtRep, ConnectionString

'
ConnectionString = "Srvr=APPSERVER;Ref=base"
'
Dest = "D:\Out\"
'
Path = LEFT(WScript.ScriptFullName, InStrRev(WScript.ScriptFullName, "\" ))
' -
LogName = Path & "errors.log"
'
ExtRep = Path & "extreport.erf"

Execute()
CheckErr()
Set ExtProc = Nothing
ComApp. Exit ( False )
Set ComApp = Nothing

Sub Execute()
Set Connector = CreateObject( "V81.ComConnector" )
Connector.Connect(ConnectionString) ' ,
Set ComApp = CreateObject( "V81.Application" )
ComApp.Connect(ConnectionString)
Set ExtProc = ComApp.ExternalReports.Create(ExtRep)
ExtProc.Path = Dest
ExtProc.Service = Path
ExtProc.Code = "42"
ExtProc.Exec()
End Sub

Sub CheckErr()
If Err.Number = 0 Then Exit Sub
Set FS = CreateObject( "Scripting.FileSystemObject" )
Set LogFile = FS.OpenTextFile(LogName, 8, True )
LogFile.WriteLine(Now & " (" & Err.Number & ") " & Err.Description & " - " & Err.Source)
LogFile.Close
Err.Clear
End Sub

* This source code was highlighted with Source Code Highlighter .

When I wrote the script, I ran into two moments that were not obvious to me.
The first is to handle exceptions without the usual try ... catch .
Having a little “tormented” about this, MSDN found that if you specify the On Error Resume Next instruction, then control will be transferred to the next line, after the one in which the error occurred. And if an error occurs in the procedure body, then control is transferred to the line following the procedure call.
Thus, I put all the main code into the Execute () procedure, and decided to catch the exceptions with the CheckErr () procedure.
The second is the “freezing” of script execution, if the information base is missing.
More precisely, if there is no database, the COM application displays a dialog box with a message about its absence and waits for the user to respond. But according to the TOR, the user will not see this and the process will “hang” ... Here I was saved by the COMConnector, which causes an exception in case of connection problems, instead of displaying dialog boxes, and two more lines appeared at the beginning of the Execute () procedure code.
')
Here Set ExtProc = ComApp.ExternalReports.Create (ExtRep) creates an instance of a COM object for an external report by contacting the External Reports manager using its English synonym.
Next, initialize the report parameters and run for execution.

Writing an external report 1C is beyond the scope of this topic, but you need to make one important note: report details, export functions and procedures that you want to make available to the Automation client should be called in English, otherwise they will not be accessible from VBScript.

If you noticed, in the connection string to the database there are no user credentials. For a successful connection, it is necessary that a user with Windows authentication by a windows user is registered in the database, on behalf of which the script is executed. I think the plus of this method is obvious.

Now it remains to place in the cmd-file a call to the script and sending utility, and ... the goal is achieved - everything works and everything is according to the TOR.