LukeParke/developer.sailpoint.com
1
0
Fork 0
mirror of https://github.com/LukeHagar/developer.sailpoint.com.git synced 2025-12-09 20:37:47 +00:00
Code Issues Packages Projects Releases Wiki Activity

Prettified Code!

Browse Source
This commit is contained in:
darrell-thobe-sp
2024-04-18 10:31:05 +00:00
committed by GitHub Action
parent f5b6aaf14f
commit 2cd5ccfc81
223 changed files with 40526 additions and 28073 deletions
Download Patch File Download Diff File Expand all files Collapse all files

123
docs/iiq/plugin-developer-guide/appendix-a/index.md
View File

@@ -8,7 +8,7 @@ sidebar_class_name: plugin_developer_guide_appendix_migration
keywords: ['plugin']
description: Migration from IdentityIQ 7.0 to 7.1
slug: /iiq/plugin-developer-guide/appendix-migration
tags: ['plugin','guide','identityiq']
tags: ['plugin', 'guide', 'identityiq']
---
# Appendix A - Plugin Migration 7.0 to 7.1
@@ -19,44 +19,44 @@ The 7.1 Plugin Framework provides a dynamic, plugin-specific class loader. It al
The object model for plugins has also changed somewhat. This table maps the old (7.0) plugin object model to the new (7.1+) plugin object model:
|**7.0 Object Model**|**7.1 Object Model**|
| --- | --- |
|uniqueName|name|
|displayName|displayName|
|enabled|disabled|
|installationDate|installDate|
|version|version|
|order|position|
|vendorName|n/a|
|vendorID|n/a|
|visible|n/a|
|allowDisable|n/a|
|allowUninstall|n/a|
|minUpgradeableVersion|minUpgradeableVersion|
|minFrameworkVersion|minSystemVersion|
|maxFrameworkVersion|maxSystemVersion|
|installationMode|n/a|
|configurationSettings|attributes|
|certificationLevel|certificationLevel|
|pluginAccessRight|rightRequired|
| **7.0 Object Model** | **7.1 Object Model** |
| --------------------- | --------------------- |
| uniqueName | name |
| displayName | displayName |
| enabled | disabled |
| installationDate | installDate |
| version | version |
| order | position |
| vendorName | n/a |
| vendorID | n/a |
| visible | n/a |
| allowDisable | n/a |
| allowUninstall | n/a |
| minUpgradeableVersion | minUpgradeableVersion |
| minFrameworkVersion | minSystemVersion |
| maxFrameworkVersion | maxSystemVersion |
| installationMode | n/a |
| configurationSettings | attributes |
| certificationLevel | certificationLevel |
| pluginAccessRight | rightRequired |
Gone in 7.1 is the idea of a plugin configuration model, and a snippet model. Instead, these elements have been rolled into the 'PluginAttributes' map that appears in the 'manifest.xml' file required by each plugin. The 'fullPage' object is now a single entry in the attributes mapping, which only holds the title of the 'fullPage'. Snippets move into a 'List' entry key in the attributes map. For each snippet entry in the 'List', implementers can define a regular expression 'regexPattern' to match against, the 'rightRequired' to see the snippet, and then a list of <Scripts/> and <StyleSheets/> that determine the look and action of the snippet.
Gone in 7.1 is the idea of a plugin configuration model, and a snippet model. Instead, these elements have been rolled into the 'PluginAttributes' map that appears in the 'manifest.xml' file required by each plugin. The 'fullPage' object is now a single entry in the attributes mapping, which only holds the title of the 'fullPage'. Snippets move into a 'List' entry key in the attributes map. For each snippet entry in the 'List', implementers can define a regular expression 'regexPattern' to match against, the 'rightRequired' to see the snippet, and then a list of <Scripts/> and <StyleSheets/> that determine the look and action of the snippet.
The most readily apparent change in plugin definition going from 7.0 to 7.1 is the location of each setting's plugins. Previously, developers could define a URL to a settings page ('settingsPageTemplateURL') that they could completely customize. In 7.1, in order to support future portability and support, the settings page has been removed, and individual plugin settings have been internalized to the 'manifest.xm'l file. These settings are now defined in a 'Settings' list in the 'PluginAttributes' map. Each element of the list is a 'Setting', which can have the following defined:
The most readily apparent change in plugin definition going from 7.0 to 7.1 is the location of each setting's plugins. Previously, developers could define a URL to a settings page ('settingsPageTemplateURL') that they could completely customize. In 7.1, in order to support future portability and support, the settings page has been removed, and individual plugin settings have been internalized to the 'manifest.xm'l file. These settings are now defined in a 'Settings' list in the 'PluginAttributes' map. Each element of the list is a 'Setting', which can have the following defined:
|Attribute Name|Description|
|---|---|
|name|Name of the current setting|
|dataType|Setting type (Ex. string or int or boolean)|
|value|Value for the setting|
|label|Display label for the setting|
|helpText|Associated help text for the setting|
|allowedValues|List of allowed values for dropdown population|
|defaultValue|Default value for the setting|
| Attribute Name | Description |
| -------------- | ---------------------------------------------- |
| name | Name of the current setting |
| dataType | Setting type (Ex. string or int or boolean) |
| value | Value for the setting |
| label | Display label for the setting |
| helpText | Associated help text for the setting |
| allowedValues | List of allowed values for dropdown population |
| defaultValue | Default value for the setting |
## Convert manifest
The first step in migrating a plugin from 7.0 to 7.1 is to review the changes that are required to move the 'manifest.xml' file to the 7.1 format. Refer to the previous chart when you're mapping old attributes to new ones. Move any plugin related settings from the unique page previously specified in the 'settingsPageTemplateURL' to the attributes map of the manifest object itself. If the previous unique page was complex, you may need to refactor the way these settings are selected.
The first step in migrating a plugin from 7.0 to 7.1 is to review the changes that are required to move the 'manifest.xml' file to the 7.1 format. Refer to the previous chart when you're mapping old attributes to new ones. Move any plugin related settings from the unique page previously specified in the 'settingsPageTemplateURL' to the attributes map of the manifest object itself. If the previous unique page was complex, you may need to refactor the way these settings are selected.
## Update UI
@@ -70,43 +70,42 @@ Refactor old JAX-RS based REST service classes that extended 'sailpoint.plugin.r
Any 7.0 plugins that extended the 'AbstractPluginBackgroundService' for a background service will now need to extend 'sailpoint.server.BasePluginService'. Details on this new class are elsewhere in this document. In addition to refactoring the service class itself, care should be taken to also modify the 'ServiceDefinition' XML object. The 'implementationClass' attribute entry is now gone. Instead, the 'executor' attribute will now change from 'sailpoint.plugin.server.PluginServiceExecutor' to the actual service that used to be listed in the 'implementationClass' entry.
### Example: A prior ServiceDefinition in 7.0
```xml
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE sailpoint PUBLIC "sailpoint.dtd" "sailpoint.dtd">
<sailpoint>
<ServiceDefinition interval="10" hosts="global" executor="sailpoint.plugin.server.PluginServiceExecutor" name="HelloService">
<Description>
A Service to demo something that runs in the background
</Description>
<Attributes>
<Map>
<entry key='pluginUniqueName' value='HelloWorld'/>
<entry key='implementationClass' value='sailpoint.plugin.helloworld.server.HelloService'/>
</Map>
</Attributes>
</ServiceDefinition>
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE sailpoint PUBLIC "sailpoint.dtd" "sailpoint.dtd">
<sailpoint>
<ServiceDefinition interval="10" hosts="global" executor="sailpoint.plugin.server.PluginServiceExecutor" name="HelloService">
<Description>
A Service to demo something that runs in the background
</Description>
<Attributes>
<Map>
<entry key='pluginUniqueName' value='HelloWorld'/>
<entry key='implementationClass' value='sailpoint.plugin.helloworld.server.HelloService'/>
</Map>
</Attributes>
</ServiceDefinition>
</sailpoint>
```
### Example: The same ServiceDefinition in 7.1
```xml
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE sailpoint PUBLIC "sailpoint.dtd" "sailpoint.dtd">
<sailpoint>
<ServiceDefinition interval="10" hosts="global" executor="sailpoint.plugin.helloworld.server.HelloService" name="HelloService">
<Description>
A Service to demo something that runs in the background
</Description>
<Attributes>
<Map>
<entry key='pluginName' value='HelloWorld'/>
</Map>
</Attributes>
</ServiceDefinition>
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE sailpoint PUBLIC "sailpoint.dtd" "sailpoint.dtd">
<sailpoint>
<ServiceDefinition interval="10" hosts="global" executor="sailpoint.plugin.helloworld.server.HelloService" name="HelloService">
<Description>
A Service to demo something that runs in the background
</Description>
<Attributes>
<Map>
<entry key='pluginName' value='HelloWorld'/>
</Map>
</Attributes>
</ServiceDefinition>
</sailpoint>
```
@@ -132,4 +131,4 @@ Due to the changes in how plugins are loaded and the inheritance of the object c
</List>
</value>
</entry>
```
```