Victor

Victor

(0 comments, 3 posts)

Consultant, trainer, release manager, people manager, coach, technical writer.

Posts by Victor

APEX: List of Values shared across various applications

When you are used to Designer 6.0 or up, you may be aware of shared or shareable components.  In ApEx Shared Components are available, too.

One specific object that is worthwhile sharing is the List of Values, LOV for short. The LOV has been known since the early Forms versions and these days it still exists. In ApEx 4.0 it is possible to create an LOV in one application and use it in others. Let’s suppose an application 100 and 200. 100 will serve as the central application that holds the core objects, LOVs in this case.

Define a number of LOVs, be it static or dynamic ones. Static LOVs contain fix predefined values, dynamic ones are basically fed by underlying tables, to be defined by the developer.  A classic example of where to store values for the LOVs is the (well-) known CG_REF_CODES table, though LOVs are not restricted to focus on this table.

Let’s assume that an LOV was defined in application 100, and we now want to use an LOV from application 100 in our other application 200. Within application 200 we have to move to the Shared Components environment.

  • Next, click on List of Values in the User Interface box.
  • Click on the yellow Create button, in the top right direction.

You will be presented with the following screen:

Select ‘As a copy of an Existing List of Values’.

Press the Next button.

In the screen as displayed below you are prompted to select an existing (other) application from where the existing LOV is to be copied:

Select the relevant application by highlighting it, and press Next.

You will be presented with a list of available LOVs from the previously selected application. At the top of the columns you will consecutively see the following names: Application, From name, To name and Copy?. The Application representing the source application, followed by the name of the LOV in that application. The To name can hold the name of the LOV in the destination application. The pop list in the Copy? column has the values No, Yes and Copy and Subscribe available.

For the purpose of this article, please set this value to Copy and subscribe.

Press the yellow button, named Copy List of Values.

In the overview of your LOVs you will be able to see what the sources are of your LOVs, see the image underneath:

The 2 LOVs on the left are copied (and subscribed) from another application. The LOV_YN is “original”, meaning that it was created in the current application. If you want to see where your LOVs are “inherited” or “copied” from press the Subscription button at the top of the screen. The LOVs that are not displayed on that list will not have been copied from another application:

The advantage of this is that you don’t need to re-define an LOV that exists in another application. You do need to be aware that somebody in charge of the “source” application may change or delete the inherited LOV, the LOV that you subscribed to.

When the person in charge of application 40000 (the application that we copied the LOVs from) wants to verify that his or her LOVs are being referenced this can be done as follows:

Please check the breadcrumbs in the picture; you can follow these to reach the relevant page in your own environment.

The LOVs listed from application 500 use this LOV, which is defined in application 40000.

Hopefully this entry in the AMIS technology blog helps you. Should you have any comments then please feel free to leave them here. Any related problems reported, feedback or questions asked will be addressed as soon as possible.

Thank you for your interest.

Lost in Service Oriented Architecture?

My initial idea was to write an article on the similarities and differences of BPEL (relatively new to me) and PL/SQL, BPEL being one option for an environment or XML-based language for defining services (What services? I’ll describe an example later…), PL/SQL being the procedural programming language that comes with Oracle (one understatement, sorry).

But hang on! If I wrote an article like that then I would assume that everybody knows PL/SQL. Well, they don’t. This article is therefore not just directed at programmers, but at anyone who wants to learn a little bit more about SOA, BPEL and Services.

When I was first introduced to the term “Services” in terms of software development I knew it wasn’t about services that you get at the next petrol station. Yet, I hadn’t realised that I myself had actually worked with services. So when people were talking about Services, or SOA, then I basically thought I still had to learn a lot (which I do, but never mind…). Until on a bright and sunny day I was talking to one of my colleagues, a very knowledgeable analyst, who pointed out to me that along with her I had worked with SOA, too, but only on the (Oracle) database side. This meant that in my activities at the time as a programmer I prepared messages, XML messages to be precise, that were sent from an Oracle database to … well, to what?

To be honest, I didn’t know. Well, I knew a little. They ominously kept calling it Tibco. Let’s – for the sake of argument – just call it a service.

(more…)

APEX: Creating a form based on a procedure

Introduction
Within ApEx for a while it has been possible to create a page (more specifically, a form) based on a procedure. A procedure enables you to build in more logic than a simple DML statement or otherwise. My example is relatively simple in that when I want to book an appointment with somebody, I do not want this appointment to overlap with somebody else’s. Maybe I even don’t want my appointment to be directly after or before another one, and want a 15 minute break.

Scenario

Build the procedure
This kind of scenario is not easy to realise if you don’t have a plan. The plan is therefore to build an INSERT statement (into a procedure, not a function!) that is only actually executed when there is enough room for my new appointment – in terms of time – in my agenda. Building this procedure is done in the Object Browser area of Apex (Home –> SQL Workshop –> Object Browser; press Create).
To check that there are actually no overlaps you need to know when the appointment starts and how long it will take. (Loads more additional features could be added, I am trying to keep the example simple for now). This justifies at least 2 IN-parameters for a procedure to be built, starting moment and duration of the appointment. Another parameter will be used to return the answer. This answer must be of a textual character (!), saying something along the lines of “Your appointment was successfully entered into your agenda”, or “Your planned appointment is overlapping with another”. Allow for at least enough characters to hold this message, as an OUT-parameter in your procedure. The procedure could look something like this…

Note the use of the parameters at the top and what purpose they serve. The OUT parameter is populated with an informative message that will appear in the form that we still have to build.

Build the page
The next step would be to build the page. It is obvious that you need to test in some way that the procedure works. Therefore relevant tables and reference data must be available.

  • Move to the relevant application and create your page. Therefore press the yellow Create page button.
  • Then select Form and press Next.
  • Then select Form on a procedure and press Next.
  • You are prompted to select the schema owner of the procedure to be used. Press Next.
  • The next screen enables you to select the relevant procedure from a list of values. What is slightly misleading is that the list of values also displays functions, which in this context are of no use, sadly. Select the required procedure and press Next.
  • Then a page displays with 7 entries, of which the compulsory entries are depicted with an asterisk:
  • A default page number is displayed. You can modify it, if you have thought up your own page numbering system. It is a compulsory entry.
    Define a page name, equally compulsory.
  • Define a region template. You can leave this as is for now.
  • The next entry, region name, is also compulsory. Make this an explanatory piece of text, as it will appear on top of the region.
  • The next two entries enable you to enter Submit and Cancel button labels. You may prefer to display labels in another language.
  • The final entry enables you to choose to have a breadcrumb displayed at the top of your page. Leave this value as is.
  • Press Next.
  • You will be presented with a screen that enables you to select a Tab (existent or now) or no tab at all. For now leave this to the default setting, and press Next.
  • Next you will see a screen quoting an optional invoking button. This is an extra button that will be created somewhere else in your collection of pages within the application, that enables you to move to the page that we are currently making. The page where you want this button to be created can be defined in the first entry, for which a list of valid values is available.
    In the second entry you can simply type the label for this button. Should you leave these 2 entries empty then no such button will be created.
    For now we will not do any such thing yet.
  • Press Next.
  • The next screen enables you to define which pages to move to when you either press the Submit or Cancel buttons. Please define two pages, making use of the offered list of values. You may even decide to use the same page for the two different buttons. Press Next.
  • Now you are presented with a screen that makes use of the parameters that were defined for the procedure involved.

  • Here you can see quoted the 3 names of the parameters, for which you can modify the labels (the names that appear in the form yet to be generated). Names in the example start with ‘D’, like the names of the parameters themselves. The 3 settings Include should be left set to Yes. In the Default entry you can set default values. The values to be entered depend on the technical functionality of the procedure. If the procedure takes care of default values then the application does not need to do so, and vice versa. Note that in this scenario dates of data type Date are involved, being D_START_DATUM. For all 3 items the Display Type may be kept to Text.
  • Please note that the D_BERICHT parameter according to the procedure will contain a message that can be used in the application.
    Press Next.
  • You will be presented with a Form on Procedure confirmation. Press Finish.
  • You will be given the options of Running or Editing the page. We are so anxious now, so press Run Page.

Something like this will be presented to you:

A few more points need to be addressed before the form will actually work properly:

  • This is hardly a form that you can present to a user. To at least make it a bit more presentable give the user a calendar display type (this would have to include the time, not just the date) when dates need to be entered.
  • A default value for the minutes (this is the number of minutes that an appointment would take) could be set at 60 or 90.
  • The D_MESSAGE can be left empty. The procedure should use this to fill in an appropriate message.
  • The previous warning in this text saying that we are dealing with data type DATE (namely D_START_DATUM) we will hit upon now. A change in one of the processes is mandatory for this form to work.
  • Finally the names of the fields and the forms need to be modified.

To address these issues we need to do the following:

    Press Edit Page xx, in my particular case it was page 13. A screen very similar to this will appear:

  • In the Page Rendering box: Right click on P13_START_DATUM.
  • Press Edit.
  • In the Name box, set Display as to Date Picker.
  • In the Label box, adjust the Label, by removing the trailing D.
  • In the Settings box, set Format Mask to DD-MON-YYYY HH24:MI (use the list of values).
  • Press Apply changes in the top right of the screen.
  • Similar steps for the Minutes entry can be executed to check that there is a default value defined.
  • When you are back in the screen where Page Rendering is at the top, right click on Run Stored Procedure underneath the Page Processing header and select Edit.
  • Modify the code as follows, noting that it is a call to the previously defined procedure, which needs to be adjusted so that the data (namely data of type DATE)is dealt with properly:
  • #OWNER#.P_ENTER_PLANDATE(
    D_START_DATUM => TO_DATE(:P13_START_DATUM, 'DD-MON-YYYY HH24:MI'),
    D_MINUTEN => :P13_MINUTEN,
    D_BERICHT => :P13_BERICHT);

  • Press Apply Changes.
  • Press Run Page, and check that the functionality is correct.

Conclusion
We can conclude that there are many things in Apex that can be realised, but sometimes Apex needs some help from us. The modification in the code that Apex made for us was not sufficient for it to work properly. When building code you will find more often that you are reminded of the fact that you are actually trying to build an application for the internet, and that browsers don’t really take data types of type date (and probably others also) into consideration.

The text in this blog is by no means complete. It is merely trying to inspire people to use – in this case – forms for a procedure. Please do not hesitate to leave any comments, feedback or additions to the text offered to you. Thank you for your attention.

Victor's RSS Feed
Go to Top