ADF BC: Create a UI table binded to Business Components

In this example we are going to show how to create a simple UI table (af:table) which is binded to Business Components.

Once again, I tried to search on the net with the simple criteria:

‘How to create an af:table binded to business components ADF 11g’

And I must admit thatI did not get the answer I was looking for. The information was there, but hidden among other solutions and examples. This can be confusing some times.. So this is a small example of how to this. I hope it will clarify you some things.

Here we go.

Do not forget to always consult the official documentation:

First, I suppose you already have an 11g version installed on your machine along with some database connection already imported to your JDeveloper. In this example we are using JDeveloper

Start your Engines! JDeveloper, ok..

After creating the Business Components. You should have something like this on your JDeveloper:

In this example we are using the Countries table from the HR schema.

Next we are going to create a simple page.

1) Go to View Controller

2) Double Click the adfc-config.xml file to open it in the editor. We choose adfc-config in this example simply because we want to focus on the af:table. We could use Bounded Task Flows but it is no mandatory for this example.

3) We open the components section from the Components palette.

4) We select the View component and we drag and drop it to the adfc-config Diagram.

We havent created our jspx just yet. As you will see in the above screen, the name of the view component is changed to index. The default name was view1. I changed it just forconvenience. You can rename it or leave it as is.

5) We double click the the index View component in order to create the page:

In this example we are going to accept the default values and we will just press ok:

After pressing ok:

6) Now it is time to create our af:table which is binded to BC.

But lets just wait a second.

What is an af:table?

According to the Documentation ( click toEnlarge):

Well, this means that we have to provide a Data Collection to an af:table.

AData Collection can be a tree binding in the pageDefinition of our jspx!

But wait.. how are we going to create this… what you say… tree binding.. and how are we going to map it to our table?? It is getting a bit complicated.. is not it?

Well, of course not! We will do it with one drag and drop!! Yes thats right! In ADF and JDeveloper, With one drag and drop we can do everything! We can create the table, and map it to our Business Components!

All we have to do is to locate the Data Controls section in our application navigator.

After locating this section, we are gong to find the HRModuleDataControl and then we will find the

Long Story Short, this Data Control, one might say, that is the Data Control produced by the HRModule Application Module (Data Model).

So, every application module we create, we have it as a Data Control in the Data Controls section of the Application Navigator.

All we have to do is to select the Iterator (View object in the Application Module) and drag-and-drop it onto the jspx as a table.

7) select the CoutnriesView1 iterator. Have the jspx open in the editor. Drag and drop it as a table:

After selecting the ADF table option, another window will appear:

8) set the table options:

The above options, let you decide basic functionalities of the table with simple checkBoxes. Furthermore, they let you control which component you want to use for every attribute of the table. You can set the value of the Display label of every attribute. Furthermore you can add or remove attribute as you want. the most common option is the Row Selection, where you can decide wether you want to select none, one or many rows in your table.

All those options, and more can be configured after you actually create the table.

9) press ok in order to create the table AND the pageDefintion file and the DataBindings file (if the pageDef already exists for this page it will be created again. It will simply be updated. The same goes for the DataBindings as well.)

the pageDef. As you can see, a tree iterBindings was created by the wizard that points to the CoutnriesViews1 iterator which leads to HRModuleDataControl:

DataBindings.cpx file. This files holds the mappings between pageDefs and their pages or method calls and generally, whatever accepts pageDefs. It is the file where you can see those mappings.

And that is it! As you can see, it is pretty easy and rather fun! a simple drag and drop, some options and here we are! we have a live and kicking af:table ready !

Of course, you can always change the properties and experiment further with this component.

Getting Started. How to create a UI table (af:table) binded to Business Components. ADF BC from our
JCG partner Dimitrios Stassinopoulos at the
Born To DeBug blog.

Source :


Programs and Technical Debt

Once you have a program (a collection of interrelated projects focused on one business goal) and you have technical debt, you have a much bigger problem. Not just because the technical debt is likely bigger. Not just because you have more people. But because you also geographically distributed teams, and those teams are almost always separated by function and time zone.

So, my nice example of a collocated team in
Thoughts on Infrastructure, Technical Debt, and Automated Test Framework, rarely occurs in a program, unless you have cross-functional teams collocated in a program. If they do, great. You know what to do.

But let’s assume you don’t have them. Let’s assume you have what I see in my consulting practice: an architecture group in one location, or an architect in one location and architects around the world; developers and “their” testers in multiple time zones; product owners separated from their developers and testers. The program is called agile because the program is working in iterations. And, because it’s a program, the software pre-existed the existence of the agile transition in the organization, so you have legacy technical debt up the wazoo (the technical term). What do you do?

Let’s walk through an example, and see how it might work. Here’s a story which is a composite from several clients; no clients were harmed in the telling of this story.

Let’s also assume you are working on release 5.0 of a custom email client. Release 4 was the previous release. Release 4 had trouble. It was late by 6 months and quite buggy. Someone sold agile as the way to make software bug-free and on-time.

You do not have automated tests for much of the code, unit tests or system tests. You have a list of defects that make Jack the Ripper’s list of killings look like child’s play. But agile is your silver bullet.

The program manager is based in London. The testers for the entire program are in Bangalore because management had previously fired all the testers and outsourced the testers. That was back in release 2. They have since hired all the Bangalore testers as employees of the Bangalore subsidiary. The program architect is based in San Francisco, and there is an architect team that is dispersed into 4 other teams: Denver, LA, Munich, and Paris. The developers are clustered in “Development Centers of Excellence:” Denver, LA, Cambridge, Paris, London, Munich, and Milan. That’s 8 development teams.

Oh, and if you think I’m kidding with this scenario, I’m not. This is what most of my clients with geographically distributed teams and programs face on a daily basis. They deserve your sympathy and empathy. Do not tell them, “Don’t go agile.” That’s nuts. They have a right to go agile. You can tell them, “Don’t go Scrum.” That’s reasonable. Scrum is for a cross-functional co-located team. Agile is for everyone. Scrum is for a specific subset.

What do you do?
  1. Assign specific testers to specific development teams. No calling people resources; that allows managers to treat people like resources and plug-and-play them. You need to get rock-solid teams together. Once you have teams together, you can name them.
  2. Name teams so the teams reflect the feature groups they work on. What does an email product do? It gets email, it sorts email, it deletes, it forwards, it creates new mailboxes, and so on. The eight feature teams had to be named for the feature areas: Platform for the general features, Sort, Delete, Forward. There were two teams who worked on Platform. They were called Platform 1 and Platform 2. At one point, someone suggested they call themselves Thing1 and Thing2 from the Dr. Seuss book.
  3. Make sure you have enough product owners so they can develop roadmaps for each feature area. With a roadmap, the teams know where they are going. Even more importantly, the architects know where the program is going.
  4. Architects think and provide just enough guidance ahead. In a small project, the architecture can probably evolve with the project. In a larger program, that risk is too large. You have too many people developing in parallel for the architecture to evolve on its own with no guidance. But I do not mean there should a Master Architect Who Knows All Handing Down the Architecture From On High. NO NO NO.
    I want the architect who is a working member of the development team, who also is part of an architecture community of practice team, who curates the architecture, who guides the business value of the architecture. I do not want Big Architecture Up Front. But Thinking Up Front? Sure, that’s a great idea. Stuck on only one idea? Bad. Willing to spike an idea? Great. Willing to play in a sandbox and debate several ideas? Great. I wrote about this before, in
    How Agile Architects Lead.
  5. Decide what done means for every feature. You must have acceptance criteria for each feature. What does that mean? You need a product owner present for each team. You still need the conversations with each team to discuss what done means. Especially with a geographically distributed team, you need the conversation when you create the backlog at the beginning of the iteration.
  6. The US development teams had trouble planning their iterations with their testers, because of the time zone differences with the testers. So, they asked their product owners if the product owner would write more than just a few phrases on the cards, because that would help them get through the iteration planning meeting faster. Someone was going to get up early or stay up late, and either way, someone was going to suffer. It made more sense to have a little bit more preparation than less sleep.
  7. Decide to do continuous integration and stick with it. Especially if you know you have technical debt and you don’t want to create more, you have to do continuous integration now. That prevents more technical debt.
  8. I have recommended to some teams that they have one-week iterations so that they stop the estimation nonsense and make their stories small. The point of estimation is so that you have an idea of what you can do as a team and not commit to more than that. The idea is that if you know what it takes to make your stories small, you will.
    Instead, we have all these crazy rituals around estimation and management tracking velocity of all things. (Yes, I’ve been drafting this post for a long time, and I wrote
    Why Does Management Care About Velocity? last week.) You know, velocity is a little like weight. Only you and your doctor need to know your weight. If you are healthy, you are fine. If you are not, you need to change something.If your team velocity is not healthy, you, as a team, need to change it. But, your management has no business butting its head in. Only you can change it.
  9. When you limit the iteration length, you tend to have the team swarm around a story. This is a tendency, not a given. If I really was the Empress of the Universe, I would decree this, but I’m not, so I won’t. If you want to decrease technical debt, or even eliminate it on your program, explain that your team will only work on one story at a time until that story is done. That story will be polished and gleaming. Fast. You will not have to worry about what kinds of testing will be done. All if it will be done.
  10. Explicitly discuss what you will automate for testing and when. In a program, I assume we will have automated system tests first. I assume we will do exploratory tests later. That’s because if you don’t start building something for test automation when you start the program and refactor as you proceed, you can never catch up. I assume every time we fix a defect, we will have an automated test for it. I also assume we build these assumptions into how we develop 🙂

So far, this is all about preventing more technical debt, not what happens when you trip over technical debt as you enter code or tests you never looked at before.

If you expected to walk into a closet, take out a shirt, and close the closet door, that’s one thing. But now, you stepped into something out of one of those death-by-hoarding shows on TV, you have an obligation to do something. You can document the problem as you encounter it; you can let the product owner know; file a defect report; write a test so you can contain the debt; and maybe you have more options. Whatever you do, make sure you have done something. Do not open the door, see the mess inside and close the door on the mess. It’s tempting. Oh my, it is tempting.

See, on programs because of the size, everything is magnified. With more people and more teams, everything is harder. Things happen faster. If you have co-located cross-functional teams, no problem. But if you don’t have co-located cross-functional teams, you have to work with what you have. And, if you already have a big legacy product, you want to address technical debt in small chunks, refactoring in small bits, integrating as you proceed.

My philosophy is this: the bigger the program, the more you need to become accustomed to working in small chunks, integrating as you go. Fully implement a small story, integrate it on the mainline. Everyone on the program does that. If you need help from an integration team, so be it.

But, if everyone only implements small stories, and everyone takes care of their own technical debt as they discover it, you don’t need an army of integration people. You only need an army of integration people when you have technical debt around integration and release. Fix that, and everyone can become responsible for their own integration.

And, if you can’t release, that’s where the architects should start. If you can’t do continuous integration, that’s where the architects should start. Because that’s what’s preventing you from making progress on the product. Work backwards from release, and then the architects can work on the rest of the product. Until you can release and build reliably, the rest of the product doesn’t matter.

Programs and Technical Debt from our
JCG partner Johanna Rothman at the
Managing Product Development blog.

Source :