This article about Enumerations follows in the footsteps of the five other parts to this series:

1. Introduction
2. Metadata Services and Load
3. Submit
4. Checkpoints
5. ExecuteQuery

This (hopefully) final part of our series discussing Intelligent Advisor and Siebel 21 covers something that can be a bit of a bugbear for a lot of Oracle Intelligent Advisor rule designers – Enumerations or, as they are better know, Value Lists. Let’s explain the issue.

In Oracle Intelligent Advisor, when integrating with (for example) Oracle B2C Service aka Oracle Service Cloud aka RightNow, the designer is delighted to see that as soon as the connection is established, then all of the Enumerations / Value Lists that are pertinent are available in the Oracle Policy Modeling client, and the relevant attributes, when mapped into the Interview, show off their values and that’s pretty cool. Refreshing the Connection will bring any changes to Oracle Policy Modeling. Notice in the screenshot below how the Source of the Enumerations / Value Lists is marked as “Connection”.

So, why is this a problem? Not for B2C Service of course, but for Siebel? Because in the standard setup, you don’t get any Enumerations / Value Lists out of Siebel. Nothing.

So you find yourself creating lots of Enumerations / Value Lists by copying and pasting them from Siebel. And when they change in Siebel you edit them. Well, that part at least makes (painful) sense. But then things get a bit weird. Suppose you create a new Value List for one of your mapped-in attributes. And you apply it to the attribute Type. And then Oracle Intelligent Advisor starts to complain, and it all goes wrong :

And it just gets worse. You cannot commit your changes because of the error, so you decide to leave the Value List and make an extra attribute just to use it, or worse still you make Lists of values in each Screen. It’s not good.

So, why doesn’t it work, and what can be done? To begin with, here is why it doesn’t work like you want it to. The metadata in Oracle Intelligent Advisor has a very simple structure when it comes to Tables and Fields (as they are known) compared to how much metadata is stored in Siebel:

<ns2:Field can-be-input="true" can-be-output="false" is-required="false" name="Name" type="STRING"/> 

This output is of course the product of some XSL Transformation during Get Metadata and Siebel runs the Workflow Process accordingly. The main part of the Workflow is just translating an Integration Object based on a Siebel structure into something that Oracle Intelligent Advisor can accept – removing a lot of Siebel metadata and building the simple format you can see above. And, for better or worse, XSLT is used for that conversion – not a Siebel functionality like Data Maps. (Sigh!)

And looking at the XSL file whose name is visible above, the issue starts to become clear. The Integration Object that is the output of this Workflow Process has the necessary structure to handle Enumerations (the Intelligent Advisor term for a Value List).

BUT the XSL file has no mention of Enumerations whatsoever. It has template sections for Tables, Fields and Links. And that’s it.

So that’s part of the problem – XSL does not handle the Enumeration “branch” of the XML that should get sent back to Oracle Policy Modeling. The second part is a little more interesting. The structure of a Field that has a value list in Oracle Intelligent Advisor metadata looks like this. I’ve included two fields, one with and one without a Value List for comparison.

<ns2:Field can-be-input="true" can-be-output="false" is-required="false" name="Name" type="STRING"/> <ns2:Field can-be-input="true" can-be-output="false" enum-type="ValueListName" is-required="false" name="Type"/>

Notice the difference. The first field has a type property. And the second has an enum-type. You cannot have both (as it makes clear in the documentation). And that is not at all handled in the basic provided XSL file. It only handles “type” not “enum-type”.

So the XSL will need to handle the “either a type or an enum-type” concept. Which in itself is not a big issue, since that is what XSLT was built for. So we can go ahead and build something like that into the file. Here is a not for real life example. We say that the enum-type is only to be added if the field is called “Location”.

<xsl:variable name="g">
<xsl:value-of select="Name"/>
</xsl:variable>
<xsl:if test="$g='Location'">
<xsl:attribute name="enum-type">ACCT_LOC</xsl:attribute>
</xsl:if>

It might mean a few more lines in the XSL file, or indeed several files, but we can certainly do this. Of course, that is only half of the story. The Enumeration “ACCT_LOC” also has to exist in the XML sent to Oracle Policy Modeling. We need Siebel to do the job of generating the standard output in the Get Metadata Workflow Process, but we want it to add the piece that is missing.

We can do that in many ways. We can dump the Value Lists to an XML file and import them into the XSL file as a template using some wizardry – perhaps pulling them out of Siebel on a regular basis (once a week / once a day) so that we can get the correct values into the file. Or we can do it in Siebel.

In the above modified Get Metadata Workflow Process, the EAILOVService is used to query one or more Siebel LOVs to retrieve their data. That service takes Then the data is converted into Enumeration format before the new, more complete structure is sent out to the Oracle Policy Modeling client.

And in the client, the Value List is shown as you would expect, in the Value List section just as soon as you connect your Interview to the Connection.

Of course this is not the end of the story – there will be more work to ensure that the load and save workflows behave accordingly when the connector sends information back and forth, but hopefully this chapter has cleared up the why and given you hope for the how!

Have a good day and see you soon.