RPC HELP Executing RPC Security Register

RPC Broker Help Home RPC Security: How to Register an RPC Security for RPCs is handled through the RPC registration process. Each client application must create a context for itself, which checks if the application user has access to a "B"-type option in the Kernel menu system. Only RPCs assigned to that option can be run by the client application. To enable your application to create a context for itself:

1. Create a "B"-type option in the OPTION file (#19) for your application. NOTE: The OPTION TYPE "B" represents a Broker client/server type option.

2. In the RPC multiple for this option type, add an entry for each RPC that your application calls. The following fields can be set up for each RPC in your option:

3. When you export your package using Kernel Installation and Distribution System (KIDS), export both your RPCs and your package option. KIDS will automatically associate the RPCs with the package option.

4. Your application must create a context for itself on the VistA M Server, which checks access to RPCs. In the initial code of your client application, make a call to the CreateContext method of your TRPCBroker component. Pass your application's "B"-type option's name as a parameter. For example: if not brkrRPCBroker1.CreateContext(option_name) then Application.Terminate; If the CreateContext method returns True, only those RPCs designated in the RPC multiple of your application option will be permitted to run.

If the CreateContext method returns False, you should terminate your application (if you don't, your application will run but you will get errors every time you try to access an RPC).

5. End-users of your application must have the "B"-type option assigned to them on one of their menus, in order for CreateContext to return True. This allows system managers to control access to client applications. For Example: Below is an example record of a user that is able to log into CPRS. Notice that there are two places that OPTION entries can be associated with a user: the PRIMARY MENU OPTION (Field #201) and the SECONDARY MENU OPTION (Field #203). Typically a normal menu option is assigned to the PRIMARY MENU OPTION, such that they can interact with VistA from the console interface (a.k.a. Roll-and-scroll mode). And the CONTEXT OPTIONS are stored in the SECONDARY MENU OPTION. Thus this user has a OR CPRS GUI CHART entry assigned to them.

Record# 102, in FILE: 200 .01-NAME : NURSE, SAMPLE A        1-INITIAL : XXX 2-ACCESS CODE :  2.2-DATE ACCESS CODE LAST CHANGED : MAR 31,XXXX 4-SEX : MALE 7-DISUSER : NO        8-TITLE : LPN (`8 in #3.1) 9-SSN : XXXXXXXX 10.1-NAME COMPONENTS : 200 (`XXXXXX in #20) 11-VERIFY CODE :  11.2-DATE VERIFY CODE LAST CHANGED : DEC 18,2XXX 16-DIVISION : Multiple Entry #69 .01-DIVISION : Family Phys of Greeneville (`69 in #4) 20.1-DATE E-SIG LAST CHANGED : MAR 31,XXXX 20.2-SIGNATURE BLOCK PRINTED NAME : XXXXXX XX XXXXXXXX 20.4-ELECTRONIC SIGNATURE CODE :  29-SERVICE/SECTION : FAMILY PRACTICE (`7 in #49) 30-DATE ENTERED : MAR 15,XXXX 31-CREATOR : TOPPENBERG,KEVIN S (`168 in #200) 31.3-PREFERRED EDITOR : SCREEN EDITOR - VA FILEMAN (`2 in #1.2) 51-KEYS : Multiple Entry #7 .01-KEY : PROVIDER (`7 in #19.1) 1-GIVEN BY : TOPPENBERG,KEVIN S (`168 in #200) 2-DATE GIVEN : MAR 31,2010 101.01-RESTRICT PATIENT SELECTION : NO   101.13-CPRS TAB : Multiple Entry #1 .01-CPRS TAB : COR (`1 in #101.13) .02-EFFECTIVE DATE : OCT 23,2009 Multiple Entry #2 .01-CPRS TAB : RPT (`2 in #101.13) .02-EFFECTIVE DATE : OCT 23,2009 200.04-MULTIPLE SIGN-ON : ALLOWED 200.06-AUTO MENU : YES, MENUS GENERATED 200.09-TYPE-AHEAD : ALLOWED 200.1-TIMED READ (# OF SECONDS) : 3600 201-PRIMARY MENU OPTION : TMG NURSE MENU (`10937 in #19) 202-LAST SIGN-ON DATE/TIME : JUN 22,XXXX 202.02-XUS Logon Attempt Count : 0 202.03-XUS Active User : No   202.04-Entry Last Edit Date : MAR 31,XXXX 203-SECONDARY MENU OPTIONS : Multiple Entry #1 .01-SECONDARY MENU OPTIONS : OR CPRS GUI CHART (`8552 in #19) 203.1-TIMESTAMP : XXXXX,XXXXXX 8932.001-PROVIDER KEY : 1