English | English
German | Deutsch
Indonesian | Bahasa Indonesia
Italian | Italiano
Spanish | Español
Turkish | Türkçe
Episode 4. 1C:Enterprise Server
The 1C proprietary file-based database is a perfect choice for development purposes. It also works great for really small production systems serving up to 5 concurrent users. Anything bigger than that, and you will start getting users’ complaints. You will hear that the system is slow, that there are periods of complete unresponsiveness followed by weird error messages, etc. Please, try to fight you primal instinct of spending big bucks on hardware upgrade as soon as you hear the word “slow.” Trust me, most probably these issues have nothing to do with the hardware performance. You’ve just reached a point when you need to switch from the file-based DB to 1C:Enterprise Server and a real-deal DBMS. This is what we’re going to discuss today.
In two-tier architecture the client application talks directly to the database. It sends queries, and process results by itself.
Three-tier architecture adds one more thing to the picture. It’s the application server that goes right in the middle between the client and the database. As for the database, we can use any of these four DBMSs, but we wll look only at MS SQL Server in this episode. Let me show you.
I’ve already installed SQL Server on a separate computer, and this is my SQL Server instance name. I use the “sa” login to connect to the server, and this is the only setting I need to make here. Now, to the 1C Server.
I’m running the Platform installer. Modify. Adding a 1C Server and its administrative tools. Next. And here are the 1C Server settings. We definitely want it to run as a service. Then we need to tell the server what user login to use. It can be Administrator, if you know its password. Or we can create a brand-new one just for the 1C Server, like this. And here we go.
OK, let’s see what we’ve got. I’m running the Computer Management Console, going to services and this is our 1C:Enterprise Server up and running. Its only mission is to serve clients: accept their requests, process them and return results.
For this to work, the server needs open network ports, and here is where they are set up. You can change them to whatever you want and, more importantly, make sure they are open in firewall settings.
Let’s look at the 1C:Enterprise server processes. I run the Task Manager, and here are the processes we’re looking for. It’s a server agent, a cluster manager and a working process. Let’s see why there are so many of them and what the server needs them for. When your system grows, more and more users send their requests to the server. And they expect to get answers. At some point, you might notice that the server’s hardware is overloaded.
At the same time, users might start complaining about slow-downs. If these two things happen together, you can start sharing the workload between several computers. In this case, the users get automatically spread between the servers, like this. This kind of configuration is called a cluster of servers, and these three processes facilitate the servers’ teamwork.
The Server Agent connects a computer to the cluster. So, you need it running on each computer you want to use as a server. The Cluster Manager coordinates this whole gang and serves as a gateway for the users to the cluster. You need only one copy of it, so we’re good right where we are.
The Working Processes are our workhorses. They deal with the users: process their requests and send back the results. Every computer in the cluster should have at least one of these, so here they go.
How do we set this all up, you might ask. First, we need to install 1C Server to each computer, of course. After this we can run the Cluster Console and add all the computers to the cluster, like this, or set up cluster parameters, like this. One more important thing. Each computer working as a part of 1C:Enterprise cluster has to have its own server license. Remember this table? These are three types of licenses 1C:Enterprise uses.
We need to install a separate server license to each of the servers, like this. The procedure of the license activation is exactly the same. As soon as you start using the server you get the message you’ve already seen, and you know what to do next.
Speaking of the licenses. What do we do with the client ones? Obviously, we cannot bother each one of our users with getting a license kit and activating it. Instead we should activate a multi-user license on one of the servers. Of course, there is much more than that to the cluster setup, but we’ll leave it for some later time.
Now, let’s learn how to migrate our infobase to the new environment using the Designer. So, this is my development workstation. I’m running the Designer and opening a file-based database my users have been working with so far. Now, I need to ask my users to log off the infobase and make sure nobody’s here but me.
I could also write a simple procedure preventing anyone from logging in using this SetExclusiveMode procedure. Now I’m just dumping the entire infobase into a DT file and saving it to my desktop. OK, we’re done here, so I’m closing this Designer and running another 1C:Enterprise.
First, let’s rename the old production infobase, like this. Now I’m adding a new infobase, giving it a name and telling the Platform to create a DBMS-based infobase rather than file-based one. Next, and here is a whole bunch of settings we need to fill out. First up: Server cluster name. This is the network name of the computer you run the 1C Server on.
If you have a cluster setup and there are several computers running the 1C Server, choose the one with the Cluster Manager on it. In my case there is no cluster, and this computer network name is My1CServer. So, this is what I type in here. Next, I need to specify the arbitrary infobase name. Let’s call it PROD again.
Next setting tells the platform how secure the connection between the client and the 1C Server should be. We can set up a secure connection during the handshake only or for the entire session, although this last option will slow down the data exchange between the client and the 1C Server.
For this specific case I don’t really need to worry about security, so I’m just leaving it disabled.
Next up: DBMS type. Microsoft SQL Server, please. Next: DBMS server instance network name. Have no idea, but let’s ask the server itself. Here is my SQL Server computer, and this is the instance’s network name. OK, back to the Designer. Copying the SQL Server instance name. Next: the arbitrary SQL database name. Let’s also call it PROD. And the next two fields - the login and the password of a user the 1C Server will use when sending requests to the SQL Server.
Please, remember that your application users never call the database server directly and therefore they don’t need personal database passwords. The only entity calling the database is the 1C Server and it needs a single password to serve all the users. So, I’m using the “sa” login and password here.
And here we go. This is my new infobase. I’m opening it with the Designer, restoring its data from the DT file, and here we go. My infobase is unrolled on the 1C Server and ready to rock!