Chatta subito con l'assistenza
Chat con il supporto

Identity Manager 9.3 - Configuration Guide

About this guide One Identity Manager software architecture Customizing the One Identity Manager default configuration Customizing the One Identity Manager base configuration One Identity Manager schema basics The full-text search in One Identity Manager Localization in One Identity Manager Process orchestration in One Identity Manager
Mapping processes in One Identity Manager Setting up Job servers
The One Identity Manager Service functionality Tracking changes with process monitoring Conditional compilation using preprocessor conditions Scripts in One Identity Manager
Visual Basic .NET scripts usage Notes on using date values Tips for using PowerShell scripts Using dollar ($) notation Using base objects Calling functions Pre-scripts for use in processes and process steps Using session services Using #LD-notation Displaying messages in the user interface Referencing packages and files in scripts Script library Support for processing scripts in the Script Editor Creating and editing scripts in the Script Editor Copying scripts in the Script Editor Testing scripts in the Script Editor Testing script compilation in the Script Editor Committing and compiling script changes Overriding scripts Permissions for running scripts Editing and testing script code with the System Debugger Extended debugging in the Object Browser
One Identity Manager query language Editing the user interface
Object definitions for the user interface User interface navigation Forms for the user interface Statistics in One Identity Manager Extending the Launchpad Task definitions for the user interface Applications for configuring the user interface Icons and images for configuring the user interface Using predefined database queries
Reports in One Identity Manager Adding custom tables or columns to the One Identity Manager schema Web service integration One Identity Manager as SCIM 2.0 service provider Processing DBQueue Processor tasks Structure of the Jobservice.cfg configuration file

Evaluation of preprocessor conditions during compilation

In order to become effective on a systemwide basis, every modification to preprocessor relevant configuration parameters as well as modifications to preprocessor conditions on objects and VB.Net expressions requires the One Identity Manager database to be recompiled.

The following is true for compiling:

  • Internal program code in the form of an #if...then...#else statement is created for objects that have a preprocessor condition. Program code in sections whose preprocessor condition does not apply, do not exist for the compiler and are therefore not parsed. These objects are assumed not to exist.

  • VB.Net expressions that contain preprocessor conditions are compiled. The program code exists. The interpretation of the preprocessor conditions is not carried out until the script is generated.

These templates are valid for compiling:

  • Templates for columns that are disabled by preprocessor conditions are not compiled and the resulting relations are not saved in the DialogNotification table. These columns are therefore considered to be non-existent.

  • Templates that relate to disabled columns cause a compiler error message if the corresponding part of code is not linked in a preprocessor statement.

Scripts in One Identity Manager

Scripts are used in One Identity Manager to monitor and maintain data consistency and customer business logic in the database. Scripts can be used to:

  • Test column values

  • Trigger events

  • Create, change, and delete objects

Detailed information about this topic

Visual Basic .NET scripts usage

One Identity Manager scripts are written in VB.Net syntax, which allows all VB.Net functions to be used. The values to be edited are given as preprocessor instructions.

NOTE: You can find detailed examples for syntax and usage of scripts on the installation medium in the QBM\dvd\AddOn\SDK\ScriptSamples directory.

You can use scripts in:

  • Templates and formatting scripts (DialogColumn table)

  • Table scripts (DialogTable table)

  • Script library (DialogScript table)

  • Task definitions (DialogMethod table)

  • Object definition selection scripts (DialogObject table)

  • Views selection scripts (DialogTable table)

  • Scripts to find the servers to carry out the process steps (Job table)

  • Process step parameters (Jobrunparameter table)

  • Process control notification (Job table)

  • Generating conditions for process steps and processes (Job and JobChain tables)

  • Process step and process pre-scripts (Job and JobChain tables)

  • Process information (Job, JobChain and JobEventgen table)

  • Mail templates (DialogRichMailBody table)

Notes on using date values

Take the following into account when using date and time.

  • If no date is given, the date 12/30/1899 is used internally. Take this into account when values are compared, for example, when used in reports.

    Example: Expression for displaying data columns in reports

    {IIF(Person.ExitDate.ToString() = "12/30/1899 12:00:00 AM","-",Person.ExitDate)}

  • Time stamps, such as insert dates or modification dates, are stored in the database with the respective UTC. The object layer transforms this time data into the currently valid time zone data when an object is loaded. The user, therefore, sees all the values in local time. When an object is saved the current time zone data is transformed into UTC data.

    NOTE: The use of DateTime.Now in scripts must be critically tested. It is better to use DateTime.UTCNow than DateTime.Now to display the value to users.

  • It is not recommended to convert date values in non-U.S. notation from the String data type to the DateTime data type in scripts:

    Value = CDate("2014-12-31")

    This always causes a problem if the script is running on a U.S. system. In the best case, you are sent an error message like "Cast from string...to type Date is not valid". In the worst case, the wrong date is returned as month and day are swapped (3.12.2014 becomes 12.3.2014).

    If possible, you should avoid a string conversion altogether in this case. The DateTime type provides several constructors for this purpose. For the example above, that would be:

    Value = new DateTime(2014, 12, 31)

    However, if the data type String is to be used, the ISO date notation should be applied as this is converted correctly in all settings:

    Value = CDate("2014-12-31")

    Value = CDate("2014-12-31 15:22:12")

    The complicated version is to input the language code format for the date:

    Value = DateTime.Parse("12.31.2014", new CultureInfo("en-US"))

    Value = DateTime.ParseExact("12.31.2014", "mm.dd.yyyy", CultureInfo.InvariantCulture)

Related Documents

The document was helpful.

Seleziona valutazione

I easily found the information I needed.

Seleziona valutazione