Alex Grant

Simple Change Request Generation via Workflow

Discussion created by Alex Grant on Dec 27, 2019
Latest reply on Jan 10, 2020 by Alex Grant

Hi folks,

 

RSA IGL provides RESTful web services to perform lots of different tasks in an automated way - one of the most useful is the "Create Change Request" web service. This allows you to perform a large number of change operations in IGL with the added benefit over standalone provisioning tasks that you have a fully approved and auditable change record. This pattern can be reused for many types of requirements, but the main design pattern provides the following qualities:

  • A single change request can be raised for multiple change items without needing to create complex loops around data sets
  • The calculation for the scope of the changes can be performed in a single SQL query rather than building data sets in the workflow

 

Identify your change scope

First off, work out which objects you wish to create change requests for and what type of change request. Each of these patterns works well for a single type of operation - for example, deleting accounts. This scope will form the bulk of your WHERE clause for building the change request XML. In this example, I will use a column that would need to be generated into a custom view or table, but this approach would work with the PV public views in the AVUSER schema as well:

WHERE account.time_since_active > 180

 

Build the change request XML

IGL web services tend to use the POST method to send and receive data. This data is typically sent in XML. XML is sometimes known for being tricky to build and parse owing to all tags needing to align and be successfully closed, but SQL provides a useful set of functions to manipulate and build XML structures. I'll be using two of them here: XMLELEMENT() and XMLAGG().

 

XMLELEMENT() defines a single XML tag and the data it contains. The data it contains can be another XMLELEMENT() function which allows for nesting of XML tags within one another.

 

XMLELEMENT("Description", 'This is a description')
--->
<Description>This is a description</Description>

 

XMLAGG() takes multiple XMLELEMENT() outputs and aggregates them into a set of child tags under a single parent tag.

 

XMLELEMENT("TopLevelTag",
   XMLAGG(
      XMLELEMENT("ChildTag", tab.value)
   )
)


--->

<TopLevelTag>
   <ChildTag>Val1</ChildTag>
   <ChildTag>Val2/ChildTag>
   <ChildTag>Val3</ChildTag>
...
</TopLevelTag>

 

Use the scope defined above to determine the WHERE clause of the SQL statement and then use XMLELEMENT and XMLAGG to build the XML.

 

SELECT
XMLELEMENT("Description", 'This is an example'),
XMLAGG(
   XMLELEMENT("AccountChange",
      XMLELEMENT("Operation", 'Delete'),
....
WHERE account.time_since_active > 180
--->
<Description>This is an example</Description>
   <AccountChange>
      <Operation>Delete</Operation>
      ....
   </AccountChange>
   <AccountChange>....</AccountChange>
   <AccountChange>....</AccountChange>
   ...

Authenticate to the application

From version 7.1.1P02, IGL has a more granular authorisation model for web services and can provided "unauthenticated" access to web services for workflows and request forms. Prior to this, you must explicitly authenticate to the loginUser web service and use the response token as part of the change request web service URL.

 

URL: https://<host>:<port>/aveksa/command.submit?cmd=loginUser

Post Request Body:

<username>$username</username>
<password>$password</password>
<authsource>$authSource</authsource>

Response Type: Properties

Response Variables: token: Job, token

 

Make the web service call

Combining the scope with the body of the XML, we can build a full POST message body for the web service. All changes are encapsulated within a <Changes></Changes> tag to identify to the web services where the changes are contained. Make sure to use the authentication token in the web services URL where required.

 

<Changes>
${jobUserData_POST_MESSAGE_XML}
</Changes>

Outcomes