Publishing Updates
Contents
- 1 Publishing Updates
- 1.1 When to Publish
- 1.2 How to Publish
- 1.3 _Composer_ Marker Section
- 1.4 IRD Objects Not Modified
- 1.5 Media Server Block Update Detail
- 1.6 Interaction Queue Block Update Detail
- 1.7 Interaction Queue View Property Update Detail
- 1.8 Workflow Block Update Detail
- 1.9 Workbin Block Update Detail
- 1.10 Deleting Items from Configuration Server
Publishing an interaction process diagram validates Project configuration information and pushes the information out to Configuration Server. When you configure an Interaction Queue, Workflow, or Workbin block, Composer does not send the information to Configuration Server until you invoke the Publish operation. This gives you complete control of the update process. When publishing an interaction process diagram, Composer also updates the Configuration Server/Object Name property of the IPD blocks for which a configuration object was created (applies to Workflow, Workbin, Interaction Queue blocks). You can set Configuration Server Preferences to:
- Automatically publish upon saving.
- Display a prompt to save before publishing.
- Delete published objects when an interaction process diagram is deleted.
- Delete published objects when a project is closed or deleted.
For information on resetting IPD Publish information, see the figure under the Reset IPD Publish Information heading in the Project Properties topic.
When to Publish
- Any time properties for any of the blocks in the IPD are changed or blocks are added/removed.
- For example, to create a Submitter Script object in the Configuration Database.
- Any time a workflow diagram is renamed. In such cases, you must go back to the Workflow block in the IPD diagram and point the block to the renamed workflow.
- If you rename your workflow Project -- this will change the deployment URL for the Project. Publishing again will point the enhanced routing object to the new URL.
- If you delete Published objects in Configuration Server, you can re-publish the diagram to create new objects.
Note: If routing blocks refer to previously unpublished queues, these references may become incorrect when the queue is published. These errors are caught by workflow validations and should be fixed by selecting the published queue in any block properties that show this validation error.
How to Publish
- Before publishing, you must connect to Configuration Server.
- Right-click an interaction process diagram in the Project Explorer.
- Select Publish to Configuration Server. The following message appears: The selected IPD diagram's data was successfully published to Configuration Server.
Once these objects are created successfully in Configuration Server, some manual configuration is still required before interactions can work. For example, to redirect e-mails to an Endpoint, you must set endpoint key in the pop-clientX section of the e-mail server Application to the correct end-point. For more details, see Deploying a Routing Application.
Overwriting Published Queues
Starting with Composer 8.1.520.##, Composer supports the ability to overwrite published queues. Users can now choose to override or ignore the existing script objects on Configuration Server when republishing an interaction script. This new functionality is very useful in multiple user environments. Prior to this release, only the first user publishing a script was considered as the owner of the project and other users (even from the same team) were restricted from publishing IPD objects to Configuration Manager.
Consider two users, A and B. A starts initial development, publishes the IPD objects, and shares the project with B. B imports the project and makes some additional improvements to contribute to the project. Prior to this release, when B tries to republish the IPD objects, the following error message is displayed:
Instead, beginning with this release, a new dialog box is now displayed when a user tries to publish interaction scripts which have already been published to Configuration Manager. The user can then select the items which needs to be re-published.
_Composer_ Marker Section
The Publish operation puts a marker section in each Configuration Database object it creates. The section name is __COMPOSER__. The section has the following keys:
Key Name | Value | Description |
source | composer | Hard-coded value to indicate object was created by Composer |
last_updated | <timestamp> | Indicates the timestamp when the publish operation was initiated that modified this object. Example: Thu Jan 07 11:26:36 PST 2010. I |
owner_diagram | <string> | Name of the Composer diagram that published this object. |
owner_project | <string> | Name of the Composer project that owns the IPD diagram in owner_diagram. |
owner_uuid | <string> | Identifier of the Composer diagram that published this object. |
IRD Objects Not Modified
The Publish operation does not modify queue and view objects that were not created by Composer. This avoids accidentally modifying objects previously created by Universal Routing's Interaction Routing Designer (IRD), which may cause issues in a legacy IRD/URS system. Using the marker section described above to indicate where the object was created, the following types of objects are not modified if they were not created by Composer:
- CfgScript of type Interaction Queue
- CfgScript of type Interaction Queue View
- CfgScript of type Workflow
Media Server Block Update Detail
The following updates are written to Configuration Server for all Media Server blocks in all IPD diagrams in the Project:
- Updates endpoints:<tenant DBID> section of specified CfgApplication.
- Each endpoint name attribute's value is set to the name of the interaction queue's CfgScript object that it is connected to. Only endpoints that were owned by this diagram, or were previously unconnected, are updated.
Interaction Queue Block Update Detail
The following updates are written to Configuration Server for all [blocks in all IPD diagrams in the Project:
- A CfgScript object (type = Interaction Queue) is created under the current tenant/Scripts folder. If the object already exists, its properties are updated.
Block Property | Configuration Server Object/Option |
Description | CfgScript object/Annex Section Queue/Description property |
Queue Enabled | State property of the CfgScript object.
If TRUE, set to CFGEnabled. If FALSE, set to CFGDisabled. |
- In the Annex of the CfgScript object, the property application is created in section Orchestration. Composer writes the value in this format: script:<name of Enhanced Routing CfgScript object where <name of EnhancedRouting CfgScript object> will be replaced with the workflow name.
This will essentially cause all views of the interaction queue to submit interactions to the SCXML application that the Enhanced Routing object points to. In the IPD, this will be a Workflow block pointing to an existing workflow diagram or an SCXML file. Note: If you rename an Interaction Queue block after its corresponding CfgScript object has been created, the object name in Configuration Server remains unchanged. Instead, the key Name in the Annex section Namespace and its value are set to the new name. Composer displays the changed name.
Interaction Queue View Property Update Detail
The following updates are written to Configuration Server for all Views defined for all Interaction Queue blocks and Workbin blocks in all IPD diagrams in the Project:
- A CfgScript object (type = Interaction Queue View) is created under the current tenant/Scripts folder. If the object already exists, its properties are updated. The name of the object follows this format: <container queue CfgScript object name>/<view name>
Block Property | Config. Server Object Type | Annex/Option Section | Key/Property |
View Name | CfgScript | Namespace | Name |
Description | CfgScript | View | Description |
Enabled | CfgScript | - | State property |
Check Interval | CfgScript | View | Freeze Interval |
Condition | CfgScript | View | Condition |
Order | CfgScript | View | Order |
Scheduling | CfgScript | View | scheduling-mode |
Parameterized Conditions (multi-valued) | CfgScript | View | Each value creates a key like "Condition.<value>" |
Database Hints (Oracle) | CfgScript | View | sql-hint |
Segmentation (multi-valued) | CfgScript | View | segment-by
Value will be "value1,value2,...valueN" |
Segment Check Interval | CfgScript | View | segment-check-interval |
Segment Limit | CfgScript | View | segment-total-limit |
Note: If you rename a View after its corresponding CfgScript object has been created, the object name in Configuration Server remains unchanged. Instead, the key Name in the Annex section Namespace and its value are set to the new name. Composer displays the changed name.
Workflow Block Update Detail
The following updates are written to Configuration Server for all Workflow blocks in the Project.
- A CfgScript object of the Enhanced Routing type is created under the current tenant/Scripts folder.
- In its annex, property url is created in section Application. The value is the URL of the generated SCXML document on the Composer web server (bundled Tomcat or local IIS). You can change this property using Configuration Manager or Genesys Administrator to set the correct value for the deployment environment.
In its annex, in section ApplicationParams, the key CustomerView_URL is added. Its value is in this format: [http:// http://]<configured CV host>:<configured CV port>. Context Services port and host values are picked up from Composer preferences.
Workflow Blocks and Publishing an IPD
This use cases below apply when Use Interaction Submitters is not enabled and you are not using Interaction Submitters.
In this case, when publishing an interaction process diagram (IPD) to Configuration Server, Workflow blocks are handled in two different ways:
Use Case #1: The Workflow block is dedicated to voice or interaction-less processing. In that case, you must use a stand-alone block (the block is not connected to any other block).
- When generating the code: Composer generates one SCXML file per such Workflow block (Name=IPD_<ipd file name>_<workflow block name>.scxml).
- When publishing: Composer creates one Enhanced Routing Script object (Name=<Project Name>.<IPD name>.<Workflow block name>) per such Workflow block in the IPD being published. The Application/url property of the ERS refers to the SCXML url (if deployed). The Workflow block Object Name property (read only property) is updated to the name of the Enhanced Routing Script object.
Use Case #2: The Workflow block is dedicated to multimedia processing. In this case, the block is connected (directly or indirectly) after a Workbin block or an Interaction Queue block.
- When generating the code: Composer generates one SCXML file per Interaction Queue/Workbin block (Name=IPD_<ipd file name>_<interaction queue block name>.scxml). If an IPD has an Interaction Queue block connected to multiple Workflow blocks (multiple views are defined on the Interaction Queue block), only one SCXML file is generated when generating the code for that IPD. This unique IPD SCXML is used to initiate the execution for all Workflow blocks. At runtime, the Workflow SCXML to execute is selected depending on the view the interaction is pulled from.
- When publishing: Composer creates one Interaction Queue Script object (Name=<Project Name>.<IPD name>.<Interaction Queue block name>) per Interaction Queue block. Composer creates one Interaction Queue View Script object (Name=<Project Name>.<IPD name>.<Interaction Queue block name>.<View name>) per Interaction Queue block defined view.
Composer creates one Enhanced Routing Script object (Name=<Project Name>.<IPD name>.<Interaction Queue block name>.Routing) per Interaction Queue block in the IPD being published. The Application/url property of this Enhanced Routing Script object refers to the Queue IPD SCXML url (if deployed). Composer does NOT create an Enhanced Routing Script object for the workflow blocks. The Workflow block Object Name property (read only property) is NOT updated.
Workbin Block Update Detail
The following updates are written to Configuration Server for all Workbin blocks in the Project.
- A CfgScript object of the Interaction Workbin type is created under the current tenant/Scripts folder. If the object already exists, its properties are updated.
- A CfgScript object of the Interaction Queue type is created under the current tenant/Scripts folder. The name of the object follows this format: <Workbin CfgScript object name>.PrivateQueue.
- A CfgScript object of the Interaction Queue View type is created under the current tenant/Scripts folder. The name of the object follows this format: <Workbin CfgScript object name>.PrivateView.
- A CfgScript object of the Enhanced Routing type is created under the current tenant/Scripts folder. The name of the object follows this format: <Workbin CfgScript object name>.PrivateQueue.Routing.
- A CfgScript object of the Interaction Queue View type is created under the current tenant/Scripts folder for each of this workbin user defined view. The name of the object follows this format: <Workbin CfgScript object name>.<view name>.
Starting with Composer 8.1.410.14, Composer generates one Submitter for each not-private view (<project name>.<IPD name>.<Workbin name>.<View name>.submitter). Each Submitter is published with the following parameters:
Submitter>Strategy=<project name>.<IPD name>.<Workbin name>.PrivateQueue.Routing Submitter>View=<project name>.<IPD name>.<Workbin name>.<View name>
Deleting Items from Configuration Server
Configuration Server objects (Enhanced Routing, Interaction Queue, Interaction Queue View, Workbin) might be deleted from the Configuration Server in following situations:
- An interaction process diagram is deleted and that IPD contained blocks for which configuration objects were created. See also Configuration Server Preferences, Delete published objects, when Interaction Process Diagram is closed or deleted option. Note that Composer must be connected to the Configuration Server in order to be able to effectively delete the Configuration objects.
- A project containing interaction process diagrams is closed or deleted and those IPD contained block(s) for which configuration objects were created. See also see Configuration Server Preferences, Delete published objects when Project is closed or deleted option. Note that Composer must be connected to the Configuration Server in order to be able to effectively delete the Configuration objects.
- An interaction process diagram is published and
- some blocks of that IPD, for which configuration objects were created, have been deleted.
- some blocks of that IPD, for which configuration objects were created, have been updated (for example some views were removed from an Interaction Queue block).
In all cases, the user is prompted for deletion confirmation for each Configuration Server object that Composer is going to delete.