Function definition requirements

All standard .NET classes and facilities are available to a function definition. The following requirements apply:

• The function must be defined as a public static method in a .NET class, compiled into a .NET assembly, and saved as a DLL.
• The function must reference the full paths to the following files in the compiler settings:
  • ExternalFunctions.dll (required)
  • PrebuiltFunctions.dll (optional)

  The files appear in the Oracle Health Sciences Central Designer client installation folder.

• The assembly containing user-defined function definitions must be self-contained. It cannot reference any other assemblies other than standard .NET framework assemblies.
• The method must return a value of one of the following types:
  • Boolean.
  • Double.
  • Int32.
  • String.
  • PFDateTime. PFDateTime is a customized version of the .NET DateTime data type that allows date time functions to handle incomplete date time fields. For more information, see Date time processing. Note that user-defined functions cannot use System.DateTime as a parameter.
  • An array of any of the listed types.
• Each parameter for the method must be of one of the listed types.
• The method cannot directly address any study objects or any other global value. It can operate only on its parameters.
• The name of the method must be the same as the name of the user-defined function.
• The function must return a value. Functions returning void are not permitted.
• The function signature must be unique for each function. (More than one function can have the same name as long as the signature is unique.) The signature of a function consists of the:
  • Function name.
  • Return type and order of the function parameters.
• Two functions that differ only in return type are not permitted because the function signature does not include the return type.
• If a study contains a user-defined function that performs a task such as reading from or writing to a file, accessing the database or the registry, making web service calls, running an external application, sending an email, or using the event log directly, the assembly for the user-defined function must be signed with a strong named signature that is valid and trusted in order for the function to work in the Oracle Health Sciences InForm application. For more information, see Securing user-defined functions.
• Function overloading is supported in accordance with C# overloading rules. The C# compiler determines the function to call based on the best match of actual parameters with the formal parameters of the overloaded function definitions. Automatic type promotion and conversion is used when resolving a function call to the appropriate definition.
• For user-defined functions that are used in studies deployed to Oracle Health Sciences InForm release 6.0 or later and require database access, apply the Read Only User Solution, which includes:
  • Read Only User Manager—Forms and command line utility to set up a read only user and save encrypted connection information to a file and registry.
  • Read Only User Connection Provider—Assembly called Oracle.HSGBU.ServicesSolutions.ROConnectionProvider.dll that contains a method to provide a database connection object for a read only user based on study name. The assembly includes the function DummyFunction() that allows the assembly to be imported into the Oracle Health Sciences Central Designer application and deployed with the study. Do not use this function in rules.

For more information, contact your Oracle Services representative.