Oracle Fusion Applications Webinar

Oracle Fusion Applications Globalization Strategy Overview,

June 10 t h , 2010
Presenter: Vice President, Terrance Wampler

MR. TERRANCE WAMPLER: Hello everyone and welcome to our next to

the last in a series of webinars around fusion applications.
Todays topic is going to be fusion applications
globalization strategy. Today, as part of this globalization
strategy, what we want to cover is what we will describe as
our internationalization, our technical architecture for how
we are going to support languages and other global
capabilities. Ill also touch on some key functional
architecture or enabling capabilities within ebase
applications. Then briefly go over the language and country
coverage that we will provide in V1.
As part of our technical foundation for globalization, I want
to first introduce some concepts to folks to make sure that
they understand how the architecture works. This first item
is something we will call internationalization. This is
often abbreviated i18n. Thats something thats come from
the industry over the years and essentially stands for the 18
letters in between I and N as part of internationalization.
Some of the cryptic things developers like do to once in
awhile. But internationalization is essentially the process
of making sure that a software product can support multiple
languages and other preferences related to global view of
business data.
Then translation is actually converting the UI strings and
seed data and other components into a language other than the
language the software was built in, most software being
designed in English. Then localization is the process of
developing specific country features for business application
for a particular market. Localization typically takes on
capabilities based on a specific product or development group
as it goes by. As part of the internationalization
foundation theres a few key terms that were going to
introduce as we go along. One is going to be called locale.
That essentially is your specific location of where youre
sitting.
This can be related to a user preference, this could be a
third party, and this could be a first party/legal entity.

Any of those business concepts as well as a system concept

like a user or a system date. That locale will be critical
in driving what we will call global features related to
language preferences, date preferences, number preferences or
even capabilities that are available to the person. Another
component of internationalization is translatability.
Theres a lot of work that goes into all of our technologies
for the entire tech stack across fusion to make sure that
they are translatable.
We have standards around making sure that expansion of words
to be able to support bi-directional languages, to be able to
support multiple character sets and other things. Thats
another concept thatll be introduced. One more piece I want
to introduce is multiple language supporter MLS that you see
on the screen and thats something thats related to the
ability to run multiple languages in a single instance of the
application. So based on specific character sets depending
on either the user or a third party preference I can support
multiple languages concurrently within either the same
session or within the same instance.
All right with some of the key terms out of the way lets
talk about how this is supported within the architecture.
The first is what we call language preferences. At any point
in time there will be a default language preference. Again
its going to be based on the persons locale. Also I may be
a person sitting in the United States or in a shared service
center in India, wherever that is and now Ill have a default
application language. I could also have a current session
language. At any particular time if I needed to go into the
application and look things up in a different language I
could do that and I could set that at any time I needed as
well.
All of this is controlled through our LDAP is therefore
security. Next lets talk about what do we translate and how
does that get translated in the application. One of the
first things that everyone should be aware of is in the user
interface where Im exposing any of the prompts that may be
available to a user. One of the things thats new in release
fusion V1 is that we have moved all of our user data into a
strings repository. What you see on the screen here is a
screenshot of the strings repository. What that allows us to
do is a couple of things.
One is it lets us remove the data from actually the code
itself. So anything that the user will see that needs to be

translated can be done separately is not part of the actual

application code. The second thing that this allows us to do
is that we provide better context to translators as theyre
looking for stuff because now I can pull things out of the
strings repository with context that describes where its
qualified, what context its in, why its there. So that
that makes it simpler. In addition to that, that allows an
addition, it allows the string repository, allows us to go
across our technology stack. The same UI that I might see in
my ADF pages inside an application can also be the same UI
that I can share in my OBIEE application or that I can share
as part of my BI publisher build app.
So I get consistency across my applications in a single
place. It also allows me to reuse text wherever possible.
Heres an example of that will look like once that interface
leverages those strings repository. On my general
preferences pages I can now see that translated very easily
and I could switch between these either with the current
session or with my default session. Next I want to talk a
little bit about the architecture for seed data and user
data. We discussed how were using a strings repository for
the user prompts across the technology stacks or UI
components that you see.
Next is the data that we might put into the database. This
might be things that we see to drive program logic or it
might be things that users enter like item descriptions or
other pieces of information that they want displayed in
multiple languages. The way that this works is the
architecture very similar to what was done in EBS. For every
base table where we might have something that needs a
description like an inventory item. What we will do is
create a translation table to support that as well. The way
that the translation table works there is a unique row for
every language that is installed.
When fusion applications are installed there will be a
primary language that is usually English for most global
instances but could be any of the languages that we support.
Then additionally you can install other languages. What will
happen is the language table will then support a row for a
description for each base table that requires specific
translation. Then the way that that is wrapped together
presented either in the UI or through reporting or some of
the other technology layers is through a language view. The
language view basically joins the base table to the language
that the user is accessing or wants preference to, to display

the actual language value as opposed to the base table value.

If in a given example a particular language does not have a
translated value; so going back to the item description.
If the primary installed language is English and a
description gets put in in English of the item but a user
wants to access the application in Japanese but no one has
created a Japanese description for that item, rather than
displaying blank it will display the description of the base
installed language until someone adds that translated value.
Then the next component of translation or data that we work
on is related to help. So we have both embedded help and we
have non-embedded help and in a previous session some of the
details of this were discussed. The embedded help because it
is accessible directly from the UI and is user immediate is
always translated.
That information will be translated and available in the
preference of the language the person is accessing. So
whether thats the default language or the current session
language it will be displayed in the language theyre running
the application in. Non-embedded help which is typically
implementation material or training material those items are
not translated. One comment that I do want to make here is
even though some of the implementation material is not
translated setup manager, does include part of these
implementation things. The embedded help related to setup
manager is translated.
Now I want to describe how the system actually leverages this
architecture when it is displaying and processing information
for users and for third parties. The way that the system
runs this as I described before is based on locale or
territory and what happens is there are a set of general
preferences that can be used. So following our own i18n
standards the internationalization features can actually be
controlled by the end-user themselves through a preferences
tab. In every one of the UI screens that youve seen today
in the way the application works the preferences will be in
the upper right-hand corner and the user at any time can
select them and change them.
Ill walk through what some of these preferences actually
are. The first is you will select the territory. In the
case of the territory preferences its going to b e used to
control the basic formatting functionality for the rest of
the things you see on this screen such as the date format,
the time format, and the currency format. Of course each one

of these can also be controlled by the user. So this can be

done at an implementation level and a role level and then a
user can override that for their own preference and then can
even be set at session time. Next, comes the date format.
Here we may have the case where theres an employee in the US
but theyre of European descent and their actual preference
even though theyre in the US, they want to override the date
format from being the default US date format of month, day,
year to be day, month, year. Next is the time format, again
same concept, while it will default based on the territory
thats provided to you, the user can override that at
anytime, same with number formatting. This means that
throughout the application no matter what the currency is
thats being displayed to them they prefer to see a number in
a specific format and they will be able to see that in the
format for them. The actual currency that they want to see
describes how they want to look at the numbers.
In this example you will see that I am using a currency US
dollar format even though Im looking Danish Kroners. And
then, of course, is my user time zone preference. This
drives other application concepts as well that Ill talk
about in a moment. Thats an overview of the technical
architecture to enable language capabilities. I also want to
get into some of the functional architecture components that
will allow us to operate global capabilities.
The first item here is a concept thats new to fusion called
a legal entity time zone. This basically allows us to
calculate what the accounting date default should be for a
given transaction if someone is writing in a global single
instance. The example that youre shown here on the screen.
We might have a shared service center thats entering
invoices for the world. In this case they may be doing it
for a US legal entity. Even though the India time is on
February 1 s t in the middle of the day the default accounting
date should still be back to January 31 s t because its for the
legal entity that the transaction is being entered.
Now in addition to this legal entity time zone there are
still the capabilities related to the user preferred time
zone. Some of the location based time zone around services
and shipments that are available. The legal entity time zone
actually drives logic to control accounting date to make sure
that accounting policies are being met based on the legal
entity for whom that transactions are being created. The
way that that is configured is on the legal entity setup.

You can see where we are picking the time zone associated to
this legal entity. It will be a default. It can always be
overridden because it is an accounting date.
Next, weve talked a lot about user preferences and the
ability to see languages and dates and other things in my own
format. But when Im dealing with third parties like
customers, suppliers, and banks I may need to operate in a
language different than the one that is my personal
preference. One of the first capabilities that we have is
the ability to support multilingual external documents. This
could be things like invoices or purchase orders where what
happens is I want to be able to present that information to
my customer in their preferred language. I may be operating
a shared service center in India but I have a customer in
Germany and theyre going to request that the purchase order
be displayed to them in German.
So I have the ability to actually print or present those
documents in the language thats preferred to them. I also
have requirements in Canada for dual language. So maybe I
need to present the information in both English and French.
I have the ability through my MLS architecture to present
multiple languages in a single document as well. Then in
addition to this in terms of usability when I am trying to
enter important information about my trading partners like
their address or their phone number and I need to make sure
that its accurate.
I typically have a variety of formats that are required
throughout the world. So within the applications we have the
ability to do flexible address and phone formats. Then
finally is we have basic capabilities when we are talking
about, again, trading partners and bank accounts, the ability
to do account validations either on reference data like their
tax payer ID or on bank accounts. These capabilities are
part of our core functional architecture which then are
pervasive throughout all of the applications.
Now finally in conclusion when we talk about our
globalization strategy the last piece well what are we
covering in V1? Based on the enabling architecture that we
covered the components that will be covered in V1 are we will
provide language out of the box capabilities for eight
languages. On the bottom here youll see American English,
Arabic, Dutch, French, German, Japanese, Spanish, and then
both traditional and simplified Chinese. In addition to this
we have the capability within the application to support

another 24 languages. So we have seeded the architecture to

support 24 languages. We are just not providing translation
of the UI strings and the seed data and some other components
for those languages pending demand.
What we have tried to do is base the languages on some of the
key markets that we think we will be able to go after for V1
adoption. Second, for some of the capabilities the global
capabilities around key components like HCM and financials.
At the top of the slide what you see are the country support.
As you would expect things like CRM and sourcing in contracts
have very good global coverage because they dont tend to
have legal requirements or other capabilities that are there.
HCM and financials have limited global capabilities in V1 and
we will be adding localizations in subsequent releases as we
go forward. That is an overview of our global capabilities
for V1 and the fusion architecture related to our global
strategy.