Welcome to the OPA Hub!


Category Archives: URL Argument

Back to Basics : Seeding from a URL Parameter

Back to Basics : Seeding from a URL Parameter

This topic comes up regularly and it often seems to get mixed up with just plain old “starting the interview from a URL”. So it’s time for a little refresher about Seeding from a URL Parameter. Time for another Back to Basics topic (catch the previous one here) !

First of all : What do we mean by seeding from a URL parameter?

Sometimes you want to start an Interview with certain attributes already populated. But this is not a situation where you are using a Connection, for example, to perform an inbound mapping loaded at start. Perhaps you are embedding Oracle Policy Automation Interviews on a Web site, and the Web site is going to pass some information into the Interview when it starts.

In pseudo-world, you want to do something like this:

https://myinterview.com/startsession/Interview/?myattribute=X

It’s really quite simple and it is becoming more frequent, since lots of Oracle Policy Automation is appearing in modern interfaces driven by JavaScript and other frameworks that support using JavaScript.

But if you try to do something like this with Oracle Policy Automation, you get a nasty surprise. It doesn’t work at all.

Then you read the documentation, and discover two or three important things that must be in place.

  1. You must authorize pre-seeding for the attribute(s) you are interested in

Seeding from a URL Parameter 1

2. You must use the seedData= tag on your URL to introduce the information to the Interview.

Armed with this you come back to your Interview and you try something like this, with impressive results:

Seeding from a URL Parameter 2

What the heck is happening here? It all seemed so simple. Well it is, but you forgot the most important point. Whatever your seeding from a URL requirements, they must be URL encoded. So the “=” character for example, is not going to get through the defences of Oracle Policy Automation. You have to encode it all first. So let’s imagine you have an attribute, whose name is my_seeded_value, and you want to populate that attribute with Richard Napier.

You need to encode part of what you are sending. You do NOT need to encode “seedData=” in fact if you do, there will be yet another error. Your URL needs to look like this :

http://xxx.com/web-determinations/startsession/URL_Seeding?seedData=

And the rest of the URL needs to be something like my_seeded_value=Richard Napier. But that part needs to be encoded. As a simple example, take it to https://www.urlencoder.org/ and put it through the encoder. It probably comes out like my_seeded_value%3DRichard%20Napier. Excellent. Now you can create the complete URL:

http://xxx.com/web-determinations/startsession/URL_Seeding?seedData=my_seeded_value%3DRichard%20Napier

And it comes out just fine:

Seeding from a URL Parameter 3

So there has definitely been an important lesson here : don’t encode seedData=, but do encode the information after it.

There is a lot more to learn about URL-based seeding, and we will continue this after the break. If you want the full online help, it is to be found here.

Have a good Holiday and see you in 2019!

Interviews, Languages and URL Arguments

Interviews, Languages and URL Arguments

The other day I was part of a discussion regarding the launch of Interviews. A couple of questions arose that formed the basis for an interesting discussion.

The details are not really important, but the basic thread was

  1. How can we be sure to launch an Interview in a specific language?
  2. How can we pass information into an Interview in respect of the language of the user?

Of course these two questions can be synthesised further to :

  1. What are the ways to find out what language the user is using?
  2. How do I pass seed information in the URL?

What language are you using?

You might be tempted to try all the different ways to do this JavaScript,  that you might find people talking about on Stack Exchange . There is basically no reliable method to detect the language of the user. Perhaps I have set the language of my Browser to German, but my Windows is in French. So which is my language? Perhaps I am in France so you can geolocate me, but I am actually a Finnish speaker? Perhaps I am in a country where geolocation is not usable or reliable? And so on…

In Oracle Siebel CRM, we have GetProfileAttr(“org.country”) available to us, for example through the JavaScript API, which will give us the Country in which we are supposed to be based. In Oracle Service Cloud we have the Country and Language in Contacts and no doubt we have other options in other applications. That will probably be the most reliable method, since it is not dependent on what the end user has done to their computer. Fine.

Suppose we want to pass that information to Oracle Policy Automation?

Let’s get down to basics.

In the image above :

  1. Whenever a Project is launched from a button, we can add the correct locale information to the URL to ensure it is launched correctly. So in the silly example above, there are two buttons. One uses”fr-FR”, the other “en-US”.
  2. This information is appended to the root URL via the ClickMe (mypath)  function.

In the third bullet, is illustrated the other part of the question. How can we pass this information into Oracle Policy Automation. using the JavaScript object we pass seedData={} into our Project. And in the seed data you can see our information being passed.

In the Interview itself, we can recover the information using the URL Argument feature in our mapped Project:

Of course the attribute can now be used in our Interview or our rules, should we need to display or leverage this information:

This little set of examples does illustrate that Oracle Policy Modelling could really do with some functions to at least allow the rule designer to capture the locale of the user (which language did they choose to view my interview in, so to speak).