Sending Service

From E-fileWiki
Revision as of 16:05, 21 December 2012 by User (talk | contribs) (1 revision: Maj WIKI SDI 20121221)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
Français Accéder à la partie française

Operating principle

The Sending Service is our solution for automatically sending reporting to the authorities.
This tool is compatible with most of the current operating systems (Windows / Unix / Linux) and is usually installed on a server on your side.
With a suitable network mapping, users can then simply copy the file to be sent in a convenient directory.
The file is then automatically encrypted and sent.

Installation of the Sending Service

A simplified update guide, easily adaptable to a new installation is available.
It describes step by step the manipulations to be performed to update or establish such a service.

In addition, for more detailed information about the architecture and the principle of operation of this tool, we invite you to consult our exhaustive documentation.


You will also find further information and sufficient explanations for the proper implementation and use of the service in the following chapters.

Prerequisites

As for the Encryption Module,the Sending Service requires a Java Runtime Environment 1.6.0_14 or higher.
Since the service is continually communicating with our server, some Network adaptations may also be necessary in order to authorize outgoing call to [www.e-http://www.e-file.lu file.lu ] HTTP and HTTPS only.

Finally, a user dedicated to the service, have to be created and linked to right e-file groups with the profile SD with response.


Settings of the properties file

A Properties file is located at the root folder of the Sending Service.

It contains all your personal information, all your needs and allows you to generate your configuration files during the physical installation.

The latter are used to start and use the sending service.
In other words :

  • It contains all the variables needed to run the service.
  • Any modification of this file must be followed by an installation to be really taken into account.


The detailed documentation, at page 15, precisely describes, field by field, the needs of this file. Do not hesitate to consult it.
You will also find in the following paragraphs, a summary of information, organized by blocks of information, necessary for the proper configuration.


More generally, the principle is to replace all '????' with your own information


Prop1.jpg e-file.hostname : www.e-file.lu for production environment, or homologation.e-file.lu for test environment.

The other items are used to indicate the login and password of your Sending Service user account and the filepath and password of your keystore.

Prop2.jpg proxy.required : up if a proxy is used to access the internet through HTTP or HTTPS.

Other values are depending on your network infrastructure. All are not mandatory.
We suggest you to consult your network team to get this information.

Prop3.jpg These parameters are used to allow or not the authorithies feedbacks and acknowledgments.

We recommand to leave these values at up

Prop4.jpg All subsequent blocks are coresponding to a particular type of reporting document.

Therefore, the aim is to identify your needs and to set to up the needed reportingXXXXXX.state parameters.
The others should necessary been set to down

reportingXXXXXX.remoteDir : Path to file location for the relevant reporting.

@PROJECT_ROOT_PATH@ : Dynamic parameter indicating the Sending Service installation path.
To change if you want to locate the user working directory elsewhere on the server or another machine.
In this case, indicate the full path to file.(separator = '/')

reportingXXXXXX.scheduleTime : Execution frequency of service to process files from this folder. (30mn by default). Feel free to reduce this value but do not fall below 5mn= 300000

reportingXXXXXX.deeplevel : Number of sub-levels to scan.
By default the value is 0, which means that only files at the root of the folder will be taken in account.

Prop5.jpg domain.descr : Not relevant. Indicate, for example the abbreviated name of your company.

domain.env.ac.id.xxx : Your 'CSSF identifyer on 7 digits, 1 code and 6 numbers. (example : P000999).

The CSSF has provided you through an official letter your password and Authentification code.

Prop6.jpg Sending Service monitoring system

If parameter is set to up, we will be able to send you an alert if an interruption of your service is detected on our side.
mon.app.origin : Unique name to provide us, without space, to enable us to identify your sending service.


Remark : At the end of setup, no '?' should remain in the configuration file

Installing and running

The installation of the sending service is quick and easy. Simply :

  • Download this file and uncompress it on a server
  • Copy your keystore in the 'keystore' folder of Service Deposant.
  • Complete the properties file as explained in previous chapter.
  • Install the service as explained at page 5 of update documentation.


Once the installation is completed, it remains to you to create the Windows service by running the InstallServiceNT.bat file. The latter is automatically generated by the installation script.
The service can be launched through the new service named Service Déposant or by running the StartServiceNT.bat file.

Remark : In case of Unix installation, simply use the files with .sh extension .

Version and update

We are able to check the version of the program you are running. This information is sent to our database when the service is launched.
On your side, the RELEASE_README.txt file, located at the root folder provides you information on the latest changes.
The current version is indicated by the first date of file. The example below indicates a version of Oktober 2012 18th :

ReleaseRdme.jpg



In all cases, if a major change occurs and if the latter has a direct impact for you, our internal process invites us to notify you via email to your local e-file administrator.

Functional testing and test environment

In fact, there is no really use to test the working of the sending service by performing a test sending.
Indeed, all technical checks are performed during the startup process.
In other words, if the startup process doesn't generate any error message, then the service is running properly.

  • Launch the sending service through the dos run.bat file or through the Windows service.
  • Wait until the end of start procedure and check the log files from log folder of Service Deposant.
  • The sending service is running properly if the error.log file is empty or contains no line about starting process.


Remark : If a problem occurs after this check, it would certainly be a functional problem or could also be linked to the e-file configuration.
In this case, we recommand to check the .err file automatically generated during the sending process.


In addition, you probably will be interested by having a test environment to validate the development of your source files or to anticipate a migration procedure.
In this case, simply :

  • Duplicate the production service by copying the whole Service Deposant folder to another location.
  • Adjust the properties file to redirect the service to our test environment : Homologation. e-file.hostname = homologation.e-file.lu

Please note that, if the user login may remain the same, the password will be changed to formation for our test environment.
Don't forget to modify the path to your test files if these ones are stored in a specific location.
Finally, to identify cleary both Windows services, we recommand to adjust the paramaters used to declare the Windows service name : wrapper.app.long.name and wrapper.app.name

  • Relaunch the sending service installation

Sending progress and follow up

The processing mode of the sending service is always the same except for semi automatic mode described in the dedicated section of Finesti Station

As an example to process a file named nomFichier.ext :

  1. When processed, the source file is renamed with .trt extension => nomFichier.ext_YYYYMMDDhhmmssmmm.trt
  2. In the same folder, a .acq file is created to acknowledge the sending --> nomFichier.ext_YYYYMMDDhhmmssmmm.acq
  3. A .err file is created in case or error --> nomFichier.ext_YYYYMMDDhhmmssmmm.err.

To understand the origin of the problem, we recommand to check the content of this file with a standard text editor.

Authorithies may also send you feedback or acknowledgment files :

  • FINESTI Reporting = Ox.x + Sx.xx + TPT = Reception of an ack file => nomFichier.ext_YYYYMMDDhhmmssmmm.ack
    This file completes the .acq file with only confirms the sending
  • CSSF Reporting listed in this document = Reception of a technical feedback= FBR with is sometimes completed by a FDB = business feedback for example in case of feebback of a signed prospectus.

These feedbacks are stored in the Replies subfolder.
You will find additionnal information on this process in CSSF documentation.

  • For other reporting (08/371 / VNI...), there is no additionnal acknowledgment.

This means that only acq will be created.


Conclusion : Checking that both trt & acq files were generated is a good way to ensure the good working of the sending service.. Doing this way, you can be sure that your data was correctly sent and e-file will be in charge of forwarding them to authoritites.

Remark : For each sending a procedure is created in www.e-file.lu and can be retrieved through the advanced search.

Common Problems

The service does not start

Please refer to following procedure if a Sending Service, launched through the Windows Services does not start in order to analyze the origin of the problem.



Attempt to start it with the DOS command line

  • Open a DOS window and make sure to have administrator rights on the computer (Start>run : cmd)
  • Move to the folder where the sending service is installed
  • Run the command : run.bat


If the sending service runs properly through this DOS command, without generating error logs, we recommand to follow this solving method.
Otherwise, a log analysis is necessary


Log Analysis

The error.log file located in the log folder at the root of Sending Service, contains the error trace causing this dysfunction.

You will find below the most common known problems.

In all cases, we are at your disposal to assist you in this analysis. Feel free to send your error log files to our SDI team.

Network Problem

Error 1 : Error when webservice's call 'obtenirVersionsDocument'.Unrecognized SSL message, plaintext connection.

Solving Method

  • Check the proxy parameters of your properties file
  • Relaunch the sending service installation process so that the changes are taken into account.

Error 2 : java.net.ConnectException: Connection timed out: connect.
Error 3 : Connection timed out: connect [TIP: The machine can be unauthorized by the proxy]

Solving Method

  • Check the configuration of your proxy with your network team.

It must be correctly configured to allow outbound connections to our server www.e-file.lu HTTP and HTTPS.

Other time out problem

Error : Startup failed: Timed out waiting for signal from JVM.

Solving Method

  • Increase the value of wrapper.startup.timeout parameter from your properties file.
    As an example, increase from 300 to 600.
  • Relaunch the sending service installation to take the changes in account.


This parameters indicates the duration allocated to the service startup. Is some cases, 5 mn may not be enough, particularly with slow proxy connectionsto e-file.


Administrator rights issue with Windows service

SDadmin.jpg

By default, a windows service runs through a non administrator system user.
Depending on your architecture, it is possible that this user account has not enough rights to ensure a proper start of the Sending Service. (proxy issue for example)

Then simply change this setting this way:


Solving Method

  • Open the Windows services window. (Start > Control Panel > Administrative tools > Services)
  • Right click on the service named ServiceDéposant
  • Select the Properties item
  • Indicate an administrator user account and password in LogOn tag.
  • Relaunch the service


Errors are raised during sending

The generation of an .err file during the processing of your report indicates an issue during the sending.

In this case, it is necessary to analyze the problem because the data could not be transmitted to the authorities.

The .err file contains the explanation of the error that generates this dysfunction.

You will find below the most common problems.
In all cases, we are at your disposal to assist you in this analysis. Feel free to send your error log files to our SDI team.


Functional Problem

Error 1 : Failed to validate XML
Error 2 : All error indicating a data problem

Solving Method

  • Correct the source file according to the erro messages indicated in the .err file.
  • Resend the file.

User account problem

Error 1 : Getting addressees information Une erreur est survenue lors de l'execution du Workflow

Solving Method

  • Link the sending service user account to the right User Group according to the kind of reporting your are trying to send.que vous cherchez à envoyer. His profils should be SD with response