Now I want to apologize in advance for
how complicated it gets right here because this really has nothing
to do with technology, and, and everything to do
with the history of the software. Our software's been around
for 25 years and, because of the
earlier dependence on the PI API,
and, and actually the continuing dependence on the PI API,
that's one layer of software for some of our
applications. That A -- those
API-based Connecting Clients actually have a different
set of Connection Credentials than the more
recent Clients that are based on the PI
SDK, that's the Software Development Kit that's more
recent than the API, the Application Programming
Interface. So, to make a long story short, if
you have got an API-based Application, like for
example, an Interface -- most Interfaces are API
based in one degree or another -- or a copy of
ProcessBook or DataLink from before version 3,
anything 2.x or 1.x, those
are, are using an API-based connection.
The Connection or coll....
Connection Credentials we get from those Applications consist
of three things: the Name of the Application;
the IP Address and the Net Mask --
and, basically the IP Address we get;
and then the Network Path which is basically the Host Name,
either the localname or the fully-qualified
name -- you know, JoePC.osisoft.com.
Now, the Application Name is a little more subtle than you might
guess, because the Application Name is restricted to just the first four
characters of the Name of the Application, plus
the letter E. Now, we have already seen an example
of this. If we take a look back at this first
example here. Here's my Trust1. Yeah, look at the
Application Name here. Application Name is
APIB and then E.
That's actually the API Buffering Application
along with the letter E. Why the letter E?
Well, it has to do with the history of the software.
Long before we settled on, on using Ethernet,
there were other networks out there and,
and we actually supported others. But, of course, Ethernet won that
war. And so, now, we distinguish,
or we , we are -- you know, the legacy of that
is that the last character in all
the Application Names for the
API Connections are always going to be an E. So, it's the first
four characters of the Application Name. That Application Name
can be determined by looking at the Log File.
If you look at your Message Log, look at how we are
attempting to connect. You will see the Name of that Application in your
Message Log. So, it's the first four
characters of that name plus the letter E.
Now, with a more modern
Client, like the PI SDK Clients of
System Management Tools, the, the current version of
ProcessBook-DataLink 3.x,
etc. Those newer applications have
those same connection criteria
plus two more. So, they have the Application Name, the
IP Address and the Network Path. But we can also
derive for them -- or from them, the Local Domain Name.
That would be, basically, the OSI -- or, excuse me, the
Windows Domain. And, we can also get the
Operating System Username. So, that would be the Windows Username.
Okay. This is, by the way, how we can
make use of the single sign-on
capability. If we can get the Windows Name, we can pass that
through and let you connect as a User who has that same
name. Now, the Application Name
is simply going to be the name of the executable. It does not follow
the same convention -- the four characters plus E. So, for
those, it would simply be, for example Procbook.exe.
That's the name of the ProcessBook Application.
Now, one final mention,
if you look at the, at the bottom of your page
on this pay... this slide, you will see notes that show you
exactly what Connection
Credentials there are for different operating systems and different
API vs SDK-based Applications.
Before we go any further, let's actually see
the effect or the Trust in action. I am running a copy of
Excel, and I can use the
add-in called PI DataLink to choose
the Connections Dialog, and I can try to connect
using the User called piadmin. As you can see, I am going to connect using
this default user. When I choose
to connect, if you recall, earlier in the class we set
a password for student, so -- or for piadmin --
so, I actually have to type in the password in order to get
in. And now, I, I am connected. If I
refresh this, I am connected as piadmin. Now, watch what
happens if we, if we
add a Trust. And, actually, let's look at
Before and After in our Message Logs. I am going to look back
the last -- let's go with the last two minutes.
And we should see that there's been a
successful login.
There we go. There is the successful login.
And, I do not
see anything in -- ... here it is. Here's a
Trust, a Trust Request.
We tried to connect. We always try to connect
first using Trust. And, in this case,
we did not pass that test. So we were prompted
with a User and Password, and finally we logged in
and it was a successful login. Now watch what happens
if we go into the Trust Database. I create a brand new Trust.
This is on my Server now. I am just going to call this MyTrust5.
And MyTrust5 is
simply going to be known by the -- the Network Path
is going to be the name of my computer, NICKGX280.
And the PI User -- let's set this to --
well, let me see. Was, was it Len?
Yeah, Len was one of our Users, and if you remember, Len has a
password. His password is Len. Now, watch what happens
when I save this.
And now I try to connect again.
I will choose PI, Connections.
I will attempt to
connect. And, as you can see, I
connected immediately. And, if we refresh this,
we can see we are connect as Len. Well, why did we -- how
did we connect as Len? If we go out to our
Message Logs -- again, let's go back the last
two minutes -- what you can find is --
yes, here it is, We are
making an initialization. We are initializing the
connection using --
well, let me see.
We are, we are initializing this
connection first
as a Trust. We are trying to see if there is a Trust that exists.
And, as you can see right here, this Trust does exist.
It is a Trust called MyTrust5, and
we are saying that when we connect that way, the User
is going to be Len. Now even though, if you
recall, Len had a password requirement. This
bypasses that entirely. We do not need
Len to type in his password because what we have simply said
is, the fact that you are in the Trust Database,
that you have been Trusted because your computer is
NICKGX280, then we are going to give you the same privileges
as Len. And that's, in fact, who I am connected as. I am connected
as Len, and even though he required a password,
the Trust Table will allow him to connect
without that password prompt. And, of course, that's
exactly what you want to happen at 4 o'clock in the morning
on a Saturday, so that you do not get that phone call
if your, your interface restarts.