View source for RPC HELP Executing RPC Security Register

[[RPC_Broker_Help| RPC Broker Help Home]]
<h2>RPC Security: How to Register an RPC</h2>
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 [[RPC_HELP_OPTION_ENTRY|OPTION]] file (#19) for your application. NOTE: The [[RPC_HELP_OPTION_ENTRY|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:	
	
    {| class="grey" border="1" cellpadding="2"
      |-
      ! Field Name
      ! Entry
      ! Description
      |-
      | RPC (#.01)
      | Required
      | This field is used to enter a pointer to the REMOTE PROCEDURE file (#8994). This field links the remote procedure call in the REMOTE PROCEDURE file (#8994) to the package option.
      |-
      | RPCKEY (#1)
      | Optional
      | This field is used to restrict the use of a remote procedure call to a particular package option. The RPCKEY field is a free-text pointer to the SECURITY KEY file (#19.1).
      |-
      | RULES (#2)
      | Optional
      | This field is used to enter M code that is executed when an RPC request is made to verify whether the request should be honored.
      |}

'''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 [[RPC_HELP_TRPCBroker_CreateContext_Method|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 [[RPC_HELP_TRPCBroker_CreateContext_Method|CreateContext]] method returns True, only those RPCs designated in the RPC multiple of your application option will be permitted to run.

If the [[RPC_HELP_TRPCBroker_CreateContext_Method|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 [[RPC_HELP_TRPCBroker_CreateContext_Method|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 [[RPC_HELP_OPTION_ENTRY|OR CPRS GUI CHART]] entry assigned to them.  

    
    Record# 102, in FILE: 200
       .01-NAME : NURSE, SAMPLE A
         1-INITIAL : XXX
         2-ACCESS CODE : <Hidden>
       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 : <Hidden>
      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 : <Hidden>
        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