Now the easiest way to understand
how the Client connects is let's just kind of follow the connection
trail. First of all, we will talk about
PI SDK-based Clients. If you recall, there're two different
types of Clients. We will talk about SDK Clients first.
Now these are typically those clients that are the more modern ones,
ProcessBook and DataLink and things like
the System Management Tools. So, the first thing the Client
need to know -- it's trying to connect to a server -- it needs to know
what is the default server and
what is the userid associated with that default server?
Now, in the case of this
PI SDK-based Client, we are going to look in something
called the known servers table. It's not a table that we really
expose to customers. It's basically a
Windows Registry entry. But, we are going to look in there,
and that's what we are going to use to populate our Connection
Dialog Box for our SDK-based
applications. Now, this is the Connection Dialog Box
for the SDK-based applications. Let me close this
and open it up again. You can get that by choosing File, Connections
within any SDK-based application.
I can learn from this. First of all,
I can learn which servers are on my known servers table,
and it's this, this list of servers here. And I can also
see, by the information down here, that
the default server is nickgx280.
So I know for a fact that that is my
default server. So, a connecting Client, by
default, unless explicitly told to connect to a different server,
is going to go to that server right there.
Now, in this case, that server has been configured
with the User, PIAdmin. So, now
we know what default ser... user goes with that.
Also, when we first configure this --
let me add a new server here. When you first add
a server, when you specify the name of
that User, you can also specify a password. So, that's information
we may or may not have stored here. In this
case, I believe I did not store a password because PI
Admin does not have a password on this machine.
But we will demonstrate it both with and without a password. So, that's the
information that we gather from the SDK-based
Client, or when an SDK-based Client
tries to connect. Now, in the
case of an API-based Client --
now remember, the API-based Clients would be the older versions of
things like DataLink and ProcessBook, the version 2.x versions
of those Clients, and also all of
the modern interfaces. Now those are going to make
use of a file called PILogin,ini.
You are going to find this in the Default Directory for
all PI Clients, so let me demonstrate where that is,
and I will show the file. I will go to the Windows Registry --
or excuse me -- to the Windows Explorer.
And, as you can see right here, this is under the Directory
called Program Files PIPC
and it's in the .dat directory. Within that .dat directory
you will find a file called PILogin.ini.
This PILogin.ini
is where we identify,
for all API-based applications, what the
defaults are. So, as you can see, there are
a lot of different servers listed here,
and if -- but if we look at the Default Section,
we can see the Default PI Server is --
well, it's that same server, nickgx280.
Now, what is the Default User that goes with this? Well, for that, we
have to do a little inspecting here.
Nickgx280 is that right there. That
maps to a computer called
PI6. So,
PI6 maps to PI6 User.
This is the Default User that is associated with that
particular computer. So,
using two different methods, we have now determined the first
things that we will need to know before we can connect. We need to know what
the Default Server is, and what --
excuse me -- and what the Default User is
for the connection.
Now, moving on further, again pretending that
we are the Connecting Client, let's take a look at what that Client will do.
First of all, if, if and only if
that Client can connect to the Server, because, obviously,
if we cannot connect to the Server using TCPIP, then we do not attempt to
connect at all. I mean we cannot go any further at that point.
But if we can connect, the --
]we will actually check for a qualifying
Trust. The Server, I should say, will check to see
if there is a Trust that allows
entry for this particular Client. Now we have not
discussed Trusts yet, but let me just demonstrate
what I am talking about. If we can switch over
to the System Management Tools, if I go into the Security
Section and Trusts, we can see there's a single Trust
that's been built for this particular --
on this particular server. This is a Trust
that is looking for a Connecting Client using that IP Address,
and if, if there is a Connecting
Client that has that IP Address, we will grant that Client
the same privileges as the User PIAdmin.
Well, let's see what happened when ProcessBook
which is up and running right now, up and running and
connected. See the connection has already been made.
Let's see what happens when ProcessBook
connected. And to do that, I am going to go into Operations
and Message Logs, and
I am not going to refresh this screen 'cause, this is
what I was hoping to see. This is from a little while ago, a couple of hours ago.
But this was when I connected for the
first time using -- or for when I connected this most recent time
using ProcessBook. And, as you can see,
there is a Trust request.
The PI base sub-system has been
requested. Is there a Trust for
this Connecting Client? Now, let me double-click
on this so that we can see it a little better. If we look at,
if we look at this right here,
right underneath here we are seeing the connecting
credentials that have been passed by the Connecting
Client. The Connecting Client has passed the followig
credentials. It says, well the, the Windows Domain is
OSI, the Windows User is Nick, the computer is
called nickgx280, the IP Address
is that, and the application is this right here.
Well, those are, you know, those are
find Connecting Clients, but, as we saw,
there is no Trust defined that will allow
that Connecting Client get
into the system. So that's why we -- that's why we
say this. There is no trust relation. We do not,
you know, we, we do not see that there's an existing Trust
that will allow this Connecting Client. So that's why,
in this case, it fails. Now, when the
Connecting Client fails, the next thing we check
or we try to do, is we
simply check to see if the username
has a password
associated with it.
Let me get back here and explain what I mean.
Yeah. So, if there is no Trust -- if there is a Trust
then we would, we would go ahead and allow the Trust login. but if
there is no Trust, we will determine what the Default
User is, and if there is no password
associated with that User, we will simply allow the connection.
If there is a password,
then we are going to throw up a Login Dialog Box and
request the User type in a password. Now, again
going back to my Message Log, as you can
see, at this point right here we did --
right after the Trust failed -- we did
accept the connection from ProcessBook. And the reason we did that,
and we did that actually without throwing up a user password prompt,
is because the connecting,
the connecting ProcessBook, it's connecting with the
Default User PIAdmin, and currently PIAdmin has no
password required. So, in our next video, we will
see what happens when you do put a password on PIAdmin.
In the last two videos we learned a lot of theory, so let's
put it to, put it into practice. Let's go into the
Trust Database and let's add a Trust. I am going to create a
New Trust that will allow me to connect to the server
nickgx280. So I am going to call this -- let's call this
myTrust1 and
this is going to be for an SDK-based application,
ProcessBook, and what I am going to specify here -- let's do it
this way. Let's just say that we want
this to be trusted because it is
the computer called
nickgx280. And, actually, I can get even more specific.
I can say, okay, let's, let's make this Trust even more
resp... restrictive. Let's only allow it
to connect if we have that
as the, as the Application Name
and that as the Computer Name. And then, when we do
that, we will be granted privileges
as -- let's say we will be granted the same
privileges as PIAdmin. Now, once I have
done that, once this Trust is in place,
we should be able to see -- ... here's the Trust
Definition. If the Connecting Client
passes these Connection Credentials, that executable,
and that network path, then we should
have a connection. So, let's -- this should
be a bit of high drama here. Let's see if I can disconnect,
explicitly disconnect,
and reconnect.
And let's see what we get in our Message Log.
So, I go into
Operations, Message Lots. Let me refresh
this. And,
and there we go. If you take
a look right here. I should not act surprised. Of course it works.
If you look at this, we have been -- or we have identified
now, that this particular
Connecting Client is going to
be granted the Trust called myTrust1.
And it was granted that because it passed
criteria. ProcBook was the name of the Process. That was the name
of this. So, now we have got a,
now we have got a new way of connecting. That's what's going to happen
if a Trust is -- if we do
match the, the connection
criteria required in that Trust.
Now let me go ahead and delete that Trust
and let me show you an alternative way. Let me delete this.
So now we are back to where we were before. Let's do
something else -- mix it up a little bit. Let's go into Users
and let's require a password on
PIAdmin. Right now, PIAdmin does not have
a password, and what I would like to
do, and I am sorry, this is the wrong place to do it. I am
currently logged in as the PIAdmin User,
so I am going to go ahead and change
the password. Currently there is no password, and I am going to
create a password.
Now, watch what
happens when we attempt to connect using
ProcessBook. I will go ahead and
switch over, and let me close
out of this. Let's go into ProcessBook.
And I will go ahead and
disconnect
and reconnect.
And notice what happened. This is the first time we have seen this.
We have been prompted with a password. That's because that User
now has a password required. I will type te... my password
here, and that
should reflect in the Message Log. If we look at
the Message Lot, we should see that
this connection has been made. This time it's been made
slightly differently. So, let's see.
Let's see if we can find --
yes, here's the Fail. Since I deleted, you know, the
Trust was granted earlier
and then I deleted the Trust,
and so when we try that Trust
Connection again, that fails. So, we do not get access to that.
We do get a successful login though.
So, if you notice we get Successful Login; Name
ProcessBook; the User, PI Admin. So as you can see, that's, those are
the methods, or those are the mechanisms and the sequences
that we are going to use when we connect from Clients that are
SDK-based.