Access Control Plug-in Programming Info

Some implementation rules apply to all Access Control Plug-in instances. This chapter covers these common implementation steps.

Creating a new instance of an Access Control plug-in at runtime

The Access Control Plug-in is loaded by any WinCC OA API based manager (including native WinCC OA managers such as UI or CTRL managers) as a shared library. This requires an external declaration of all available methods. To avoid this additional effort, a plug-in factory exists. You need to instantiate a new Access Control Plug-in Class by using this factory functionality any time for your Access Control Plug-in Class (typically filled in by the name given in the newWCCILAccessCtrlPlugin.cmd):

// defines the factory function for this Access Control Plug-in

SECURITY_PLUGIN(<Name of your plug-in>)

e.g. SECURITY_PLUGIN(myPlugin)

When you generate your plug-in, see Generating a User-Defined Plug-in, the plug-in contains the factory function.

As example see the code of the Demo Access Control Plug-in newWCCOAAccessControlPlugin.cmd located in your WinCC OA installation/api directory.

Figure 1. api directory and newWCCOAAccessControlPlugin.cmd

A debug flag for log output

To control the output of debug texts the debug flag for the Access Control Plug-in can be used.

The default for this debug flag is “ACCPLUGIN” to be used on the command line of any manager of interest e.g. WCCOAui –m gedi –dbg “ACCPLUGIN” .

To change the name of the debug flag for your Access Control Plug-in update the corresponding line inside of the constructor of your custom Access Control Plug-in:

//Creates a debug flag with the given name.

dbgFlag = Resources::registerDbgFlag("ACCPLUGIN_NEW");