OAUG Fusion Middleware BootCamp Chicago – Part II

Today was the first day of the FM BootCamp.
After a brief introduction of the program we started with our first topic of this two-week intensive hands-on Fusion Middleware Experience.

Roughly, the four topics to be covered during this BootCamp are:

1. Introduction to XML – 2.5 days
2. WebServices – 1.5 days
3. BPEL – 3 days
4. XML Publisher – 3 days

So, today we set off with XML. This is a fairly new topic for me. I have seen XML, obviously. As an EBS DBA you cannot work your way around XML. You will find XML files all over the place in an E-Business Suite. Take for example the environment definitions. They are mostly taken from XML files, in stead of defining environment variables in all different places.
Having said this, it doesn’t actually mean that one really understands how it works.

Well, today was the chance to really make a start with understanding XML and the versatility of this language.

We first started with an introduction of XML, like what it really is, how it works, the standards, Namespaces, DOM, SAX, XPath, XSL/XSLT etc. Then, we got a brief introduction to JDeveloper (Wow! Will I – a typical EBS DBA – really be doing this?;-), in order to use this for creating XML documents, which was the second topic of the day.

Creating XML documents is not really that difficult. It works quite like HTML, only much more flexible. The trouble – for me, at least – began with the validation part: DTDs. Interesting stuff though. To actually do some basic validation of the structure of an XML file by referencing the document to a Document Type Definition (DTD), in which the structure of an XML file is defined.

For example, employees.dtd containing the following information:

<!ELEMENT employees (employee+)>
<!ELEMENT employee (employee_id, last_name)>
<!ATTLIST employee manager_id CDATA #IMPLIED department_id (10|20|30) '40'>
<!ELEMENT employee_id (#PCDATA)>
<!ELEMENT last_name (#PCDATA)>

will validate the following (employee.xml) document:

<?xml version="1.0"?>
<!DOCTYPE employees SYSTEM "employees.dtd" [
<!ENTITY title "Mr">
]>
<employees>
  <employee manager_id="100" department_id="20">
    <employee_id>100></employee_id>
    <last_name>&title; Roth</last_name>
  </employee>
</employees>

For those of you who don’t know about XML (like me, ;-)):

• In the dtd file I have specified that the element “employees” must appear at least once in the xml file (the + sign);
• the (sub-)element “employee” can occur only once under employees (no specification like e.g. + after the declaration);
• the element “employee” must contain “employee_id” and “last_name”;
• the attributes of employee (the values specified in the element “definition” – manager_id and department_id in this case) can optionally “contain manager_id” but must contain “department_id”
  and department_id will be validated against the given values (10, 20 or 30, and if a value is omitted, the default of 40 will be used);
• Finally, the elements employee_id and last_name contain values that will be parsed (#PCDATA).

This dtd file is called from the xml file by use of the !DOCTYPE parameter. However, in this xml file one dtd parameter has been used to define the title. You can use local (internal) DTD declarations to override the external DTD declarations, or define new declarations that are not covered in the external DTD. These are referred to with the & in the XML code (&title in the last_name element).

Some of you might think this as the real basic stuff, which it is, obviously. But hey, one has to start somewhere! I am a complete analphabetic in this area 😉 and I am learning something new here.

The last thing covered today was the topic Namespaces. This is still a bit fuzzy to me, as it is not completely clear to me why we would use something like namespaces.
Apparently, namespaces are to provide unique names for elements and attributes, to resolve name ambiguity / collision problems when combining XML document fragments, or when multiple elements have similar type/attribute names in the same XML documents. I can understand this theory, but when namespaces are necessary to use is not really clear (in practice) yet. Well, we’ve just finished day 1 only, maybe (and I guess) it will become clearer somewhere in the next days/weeks.

That’s it for now. It was a really nice day (from a learning perspective; the weather didn’t cooperate too much, as opposed to yesterday, but after all, we spent the whole day in the office…)

I hope to come back tomorrow with another report.