Application Developer's Guide
|
 |
 |
|
|
 |
 |
This chapter describes how to use the Liquid Data control in WebLogic Workshop to develop applications that use data from Liquid Data queries. Applications can use the data to display results in a web application, to use in a Web Service, to use as an input to a WebLogic Integration business process, or in many other ways. The following topics are included:
WebLogic Workshop allows you to create Liquid Data Controls. The Liquid Data Control is a Java Control, and it allows you to very rapidly generate robust applications that use results from Liquid Data queries (for example, to display in a web application or to use in a WebLogic Integration business process). This section describes the Liquid Data control and the applications you can create with it.
The Liquid Data Control is available in WebLogic Workshop. The Liquid Data Control is an extensible Java Control that accesses the Liquid Data server to execute queries from applications developed in WebLogic Workshop. The Liquid Data Control is available with all of the other Java Controls in WebLogic Workshop (for example, the database control). When you use the Liquid Data Control in WebLogic Workshop, Workshop displays a query wizard which connects to a Liquid Data server to get the query metadata needed for configuring the control. After you select the queries to use in your Liquid Data Control, Workshop generates XMLBean classes for the target schemas associated with the queries and then generates a Liquid Data Control (.jcx) file.
When you create a Liquid Data control in WebLogic Workshop, the Liquid Data Control wizard generates XMLBean classes for each query in the control. The Liquid Data Control wizard uses the schema associated with the stored query in the Liquid Data repository to generate the structure for the XMLBean classes. The XMLBean classes provide Java methods to traverse the XML result set returned from Liquid Data.
The XMLBean classes are automatically generated in a schema project in the workshop application. There is one schema project per Liquid Data Control (.jcx) file.
You can use the Liquid Data Control like other controls in WebLogic Workshop, and you can take advantage of Workshop features to use Liquid Data Controls in Web Services, Page Flows and WebLogic Integration business processs. For example, you can generate a page flow from your Liquid Data control and then use the XMLBeans to bind the data returned from Liquid Data to the JSPs in your application.
When you create a Liquid Data Control, WebLogic Workshop generates a Java Control Extension (.jcx) file. The file contains methods corresponding to the queries in which the control accesses, shows the schema files of each query as a comment, and contains a commented method which, when uncommented, allows you to pass any XQuery statement to execute an ad-hoc query. This section describes the Liquid Data Control (.jcx) file and includes the following sections:
The design view of the Liquid Data Control (.jcx) file shows the available methods in a graphical view.
Figure 2-1 Design View of a Control File
With the right-click menu, you can add, modify (for example, change the query accessed by a method), rename, and delete methods. The right-click menu is context-sensitive; it displays different items if the mouse cursor is over a method, or in the control portion of the design pane.
The source view shows the source code of the Java Control Extension (.jcx) file. It includes as comments the schema used to generate the XMLBean classes for each query. The signature for each method shows the return type of the method. The return type is the XMLBean class which was generated for the schemas.
This file is a generated file and the only time you should need to edit the source code is if you want to add a method to run an ad-hoc query, as described in Running Ad-Hoc Queries through the Liquid Data Control.
The following shows the source code for a generated Liquid Data Control (.jcx) file. It shows the package declaration, import statements, connection properties, the schema project and filename used with the ApplOrderDetailView query, and the method that executes the ApplOrderDetailView query.
package myFolder;
import weblogic.jws.control.*;
import com.bea.ld.control.LDControl;
/**
* @jc:LiquidData urlKey="myApp.myAppWeb.myFolder.anotherLDControl"
*/
public interface anotherLDControl extends LDControl, com.bea.control.ControlExtension
{
/* Generated methods corresponding to stored queries.
*/
/**
* @return Schema Project: myAppWeb-myFolder-anotherLDControl-Schemas
Schema File: rtl\OrderDetailView.xsd
TargetNamespace: urn:retailer
Element Name: OrderDetailView
*
* @param orderid java.lang.String
*
* @param custid java.lang.String
*
* @jc:Stored-Query Name="rtl.ElecOrderDetailView"
*/
retailer.OrderDetailViewDocument ElecOrderDetailView
(java.lang.String orderid, java.lang.String custid);
/**
* Default method to execute an ad hoc query.
* This method can be customized to have a differnt method name
* (e.g. runMyQuery), return a XML Bean class (e.g. Customer),
* or to have one or both of the following two extra parameters:
* com.bea.ldi.server.common.QueryParameters and
* com.bea.ldi.server.common.QueryAttributes
* e.g. exec(String query, QueryParameters params);
* e.g. exec(String query, QueryAttributes attrs);
* e.g. exec(String query, QueryParameters params,
* QueryAttributes attrs);
*
com.bea.xml.XmlObject executeXQuery(String query);
*/
}
The XMLBean classes corresponding to the queries in the Liquid Data Control (.jcx) file are generated in a schema project. There is one schema project for each control. The schema project(s) also contain a copy of the schema files associated with the queries in the Liquid Data Control (.jcx) file. The JAR file for the XMLBean classes is generated in the Libraries directory of your WebLogic Workshop application.
The @return Schema Project section of the generated Liquid Data Control (.jcx) file displays the location of the schemas corresponding to the query method below this section in the control file. For example, the following code snippet from a generated Liquid Data Control (.jcx) file shows the name of the schema project and the name of the target schema.
/**
* @return Schema Project: myAppWeb-myFolder-anotherLDControl-Schemas
Schema File: rtl\OrderDetailView.xsd
TargetNamespace: urn:retailer
Element Name: OrderDetailView
*
* @param orderid java.lang.String
*
* @param custid java.lang.String
*
* @jc:Stored-Query Name="rtl.ElecOrderDetailView"
*/
retailer.OrderDetailViewDocument ElecOrderDetailView
(java.lang.String orderid, java.lang.String custid);
The name of the schema project is myAppWeb-myFolder-anotherLDControl-Schemas, and the schema file is in the rtl subdirectory and is named OrderDetailView.xsd. Figure 2-2 shows the generated schema project in WebLogic Workshop.
Figure 2-2 Generated Schema Project in WebLogic Workshop
At the bottom of the generated Liquid Data Control (.jcx) file is a comment showing methods you can add which allow you to run an ad-hoc query through the control. To add one of these methods, uncomment the appropriate method and add a return type to the signature.
/**
* Default method to execute an ad hoc query. This method can be customized
* to have a differnt method name (e.g. runMyQuery), return a XML Bean class
* (e.g. Customer), * or to have one or both of the following two extra
* parameters: com.bea.ldi.server.common.QueryParameters and
* com.bea.ldi.server.common.QueryAttributes
* e.g. exec(String query, QueryParameters params);
* e.g. exec(String query, QueryAttributes attrs);
* e.g. exec(String query, QueryParameters params, QueryAttributes attrs);
* com.bea.xml.XmlObject executeXQuery(String query); */
You can create Liquid Data controls in a variety of WebLogic Workshop projects. This section includes the following procedures to create Liquid Data controls:
The steps are similar for creating Liquid Data controls in other types of WebLogic Workshop projects.
This section describes the general steps for creating a Liquid Data control. For detailed steps for creating a Liquid Data control in a Web Project or in a Web Service project, see To Create a Liquid Data Control in a Web Project or To Create a Liquid Data Control in a Web Service Project.
Before you can create a Liquid Data control in WebLogic Workshop, you must create an application and create a project in the application. You can create a Liquid Data control in most types of Workshop projects, but the most common projects in which you create Liquid Data controls are Web Projects, Web Service Projects, Portal Web Projects, or a Process Web Projects.
Make sure the Liquid Data server is running. The Liquid Data server can be running locally (on the same domain as WebLogic Workshop) or remote (on a different domain from workshop). If the Liquid Data server is not running, start up the domain in which it runs.
Create a folder in the project to hold the Liquid Data control(s). You can also create other controls (database controls, for example) in the same folder, if needed. Workshop controls cannot be created at the top-level of a project directory structure; they must be created in a folder. When you create the folder, enter a name that makes sense for your application.
Figure 2-3 Create a New Folder in WorkshopLiquid Data
The Liquid Data Control is a Java Control Extension. To create a Liquid Data Control, start the Java Control wizard by selecting your folder within a project, right-clicking, and selecting New —> Java Control, as shown in Figure 2-4. You can also create a control using the File —> New—> Java Control menu item.
Figure 2-4 Create a New Liquid Data Control
Then select Liquid Data from the New Java Control Extension dialog, as shown in Figure 2-5. Enter a filename for the control (.jcx) file and click Next.
Figure 2-5 Liquid Data Control in WebLogic Workshop
Note: The LiquidDataControl.jar file is copied into the Libraries directory (if it does not already exist) of your application when you create a Liquid Data Control.
A screen similar to the one in Figure 2-6 allows you to enter connection information to your Liquid Data server. If the server is local, the Liquid Data control uses the connection information stored in the application properties (to view these settings, access the Tools —> Application Properties menu item in the IDE).
If the Liquid Data server is remote, click the Remote button and fill in the appropriate server URL, user name, and password.
Note: You can specify a different username and password with which you connect to a local machine on the Liquid Data Control Wizard Connection Information dialog, too. To do this, click the Remote button and enter the connection information (with a different username and password) for your local machine. The security credentials specified through the Application Properties or through the Liquid Data Control Wizard are only used for creating the Liquid Data Control (.jcx) file, not for testing queries through the control. For more details, see Security Considerations With Liquid Data Controls.
When the information is correct, click Create to go to the next step.
Figure 2-6 Liquid Data Control Wizard—Connection Information
In the Select Liquid Data Queries screen, select queries from the left pane and click Add to add those queries to the control. If you mouse over a query, the signature of the control method for the query appears in a tooltip popup. A "fetching metadata" message appears if the signature has not yet been retrieved from the Liquid Data server.
Note: Only stored queries with a schema configured appear in the Stored Queries list. For details on configuring stored queries, see Configuring Stored Queries in the Administration Guide. You can also deploy stored queries from directly from the Data View Builder, as described on Deploying a Query in Building Queries and Data Views.
Select one or more queries, add them to the right pane, and click Finish. When you click Finish, the Liquid Data Control (.jcx) file is generated and XMLBean classes corresponding to the schema for each stored query in the control are generated. The XMLBeans are stored in the Libraries directory of the Workshop Application. In the Libraries directory, there is one JAR file for each Liquid Data control, with the XMLBeans included in the JAR file. The JAR files are named according to the project and directory hierarchy for the control (.jcx) file.
Figure 2-7 Liquid Data Control Wizard—Select Queries
Note: The stored queries should be named according to the Naming Conventions for Stored Queries described in Building Queries and Data Views. If a stored query contains illegal characters (for example, a hyphen), the method generated in the Liquid Data Control (.jcx) file might be an invalid Java name, causing compilation errors. If a method name is invalid, you can change the name to make it valid.
Clicking the New Query button launches the Data View Builder. You can then use the Data View Builder to create, modify, test, and deploy new queries.
The Refresh button updates the stored query list from the Liquid Data server. If you create and deploy a new query with the Data View Builder, click the Refresh button to display the new query in the wizard.
This section describes the basic steps for creating a Liquid Data control in a new Web Project. If you are adding the control to an existing project, you might not need to perform each step (for example, creating a new project). Perform the following steps to create a Liquid Data control in a new WebLogic Workshop Web Project.
Workshop generates the .jcx Java Control Extension file for your Liquid Data control. Each method in the .jcx file returns an XMLBean type corresponding to the stored query schema. The XMLBean classes for each query are automatically generated when you create the Liquid Data control. The XMLBean classes are stored in the Libraries directory of the Workshop Application.
This section describes the basic steps for creating a Liquid Data control in a new Web Service. If you are adding the control to an existing Web Service, you might not need to perform each step (for example, creating a new project). Perform the following steps to create a Liquid Data control in a new WebLogic Workshop Web Service Project.
Workshop generates the .jcx Java Control Extension file for your Liquid Data control. Each method in the .jcx file returns an XMLBean of the type corresponding to the schema from the stored query. The XMLBean for each query is automatically generated when you create the Liquid Data control. The XMLBeans are stored in the Libraries directory of the Workshop Application.
Perform the following steps to add a Liquid Data Control to an existing Web Service .jws file.
Figure 2-8 Add a Liquid Data Control to Web Service
Figure 2-9 Insert Control Wizard
Perform the following steps to generate and test a web service from a Liquid Data Control.
startTestDrive and finishTestDrive methods, as well as a method for each of the queries you specified in the Liquid Data Control wizard.
This section describes the ways you can modify an existing Liquid Data control. It contains the following procedures:
Perform the following steps to change the query that a method in a Liquid Data Control accesses.
Figure 2-10 Changing the Query a Method Accesses
Note: You can also access the Liquid Data Control Wizard from the property editor
Figure 2-11 Opening the Property Editor from the Stored-Query Name Property
Perform the following steps to add a new method to an existing Liquid Data control.
Figure 2-12 Add a Method to a Control
Alternately, you can launch the query wizard from the Stored-Query name property, as shown in Figure 2-11.
You can use the query wizard to modify one or more queries accessed in an existing Liquid Data Control. A query corresponds to a method in the Liquid Data Control (.jcx) file. Perform the following to invoke the Liquid Data query wizard and modify the query selection for an existing Liquid Data Control.
url or username attributes in the property editor.Figure 2-13 Invoking the Query Wizard from the Workshop Property Editor
url or username attributes, or if the Liquid Data Server is in a remote domain, the Liquid Data Connection Information screen appears. Enter a password and click OK. If you did not change the value of these attributes, then the wizard opens to the Property Editor where you select queries.If any of the schemas corresponding to any methods in a Liquid Data Control change, then you must update the Liquid Data Control to regenerate the XMLBeans for the changed schemas. Perform the following steps to update a Liquid Data Control
WebLogic Workshop includes NetUI, which allows you to rapidly assemble applications that display data returned from Liquid Data queries.
When you create a Liquid Data control, XMLBean classes are generated for the target schema of each stored query included as a method in the control. The following sections represent the basic steps for using NetUI to display results from a Liquid Data Control:
You can generate a page flow from a Liquid Data Control (.jcx) file. When you generate the page flow, Workshop creates the page flow, a start page (index.jsp), and a JSP file for each method you specify in the Page Flow wizard.
Perform the following steps to generate a page flow from a Liquid Data control.
.jcx) file from the application file browser, right-click, and select Generate Page Flow.Figure 2-14 Enter a Name for the Page Flow
Figure 2-15 Choose Liquid Data Methods for the Page Flow
Workshop generates the .jpf Java Page Flow file, a start page (index.jsp), and a JSP file for each method you specify in the Page Flow wizard.
.jpf file for the XMLBeans. For details, see Adding XMLBean Variables to the Page Flow.You can add a Liquid Data Control to an existing Page Flow .jpf file. The procedure is the same as adding a Liquid Data Control to a Web Service, described in To Add a Liquid Data Control to an Existing Web Service File, except instead of opening the Web Service in Design View, you open the Page Flow .jpf file in Action View.
You can also add a control to an existing page flow from the Page Flow Data Palette (available in Flow View and Action View of a Page Flow), as shown in Figure 2-16.
Figure 2-16 Adding a Control to a Page Flow from the Data Palette
In order to use the NetUI features to drag and drop data from an XMLBean into a JSP, you must first create one or more variables in the page flow .jpf file. The variables must be of the XMLBean type corresponding to the schema associated with the query. If you create a single variable at the top level of the XMLBean class (the same as the return type of the method in the Liquid Data Control (.jcx) file), the NetUI repeater wizard can then access all the data from the query.
Defining a single variable in the page flow .jpf file for the top-level class of the XMLBean (the same as the return type of the method in the Liquid Data Control (.jcx) file) provides you access to all the data from the query (through the NetUI repeater wizard). When you create the Liquid Data control and the XMLBeans are generated, the XMLBean generation defines an array for each element in the schema that is repeatable. You might want to add other variables corresponding to other arrays in the XMLBean classes to make it more convenient to drag and drop data onto a JSP, but it is not required. Define each variable with a type corresponding to the XMLBean object of the parent node.
Define the variables in the class that extend the PageFlowController class. For example, consider the case where you are trying to display XML data of the following form:
<CUSTOMER>data</CUSTOMER>
......<PROMOTION>promotion data</PROMOTION>
......
You can add the following code snippet, which shows two variables (shown in bold type) added to the page flow:
public class myPageFlowController extends PageFlowController
{
/**
* This is the control used to generate this pageflow
* @common:control
*/
private aLDControl myControl;
// Add public Variables with XMLBeam types from the generated XMLBeans.
// The type matches the return type of the method corresponding to the
// query in the Liquid Data Control (.jcx) file.
public com.mycorp.crm.CUSTDocument aVar;
This code snippet declares one variable in the page flow, aVar, and the variable will display in the IDE to allow for drag-and-drop operations onto JSP files.
Note: The variables of XMLBean type in the page flow must be declared public.
You must also initialize the variable in the page flow method corresponding to the page flow action that calls the query. For details, see To Initialize the Variable in the Page Flow.
Figure 2-17 Page Flow Variables for XMLBean Objects
When you drag-and-drop an array onto a JSP file, the NetUI Repeater Wizard appears and guides you through selecting the data you want to display.
Perform the following steps to add a variable of XMLBean type for your query.
XMLBean type corresponding to the schema elements you want to display. Depending on your schema, what you want to display, and how many queries you are using, you might need to add several variables.XMLBean. Create a variable of that type. For example, if the signature for a control method is as follows:mySchema.CUSTOMERPROFILEDocument myQuery(java.lang.String custid);
You must initialize your XMLBean variables in the Page Flow. Initializing the variables ensures that the data bindings to the variables work correctly and that there are no tag exceptions when the JSP displays the results the first time.
Perform the following steps to initialize the XMLBean variables in the Page Flow:
The following sample code shows an example of initializing a variable on the Page Flow. The code (and comments) in bold is what was added. The rest of the code was generated when the Page Flow was generated from the Liquid Data control (see Generating a Page Flow From a Control).
/**
* Action encapsulating the control method :RTLCustomerProfile
* @jpf:action
* @jpf:forward name="success" path="index.jsp"
* @jpf:catch method="exceptionHandler" type="Exception"
*/
public Forward RTLCustomerProfile( RTLCustomerProfileForm aForm )
throws Exception
{
schemasBeaComLdCustview.PROFILEVIEWDocument var =
myControl.RTLCustomerProfile( aForm.custid );
getRequest().setAttribute( "results", var );
//initialize the profile variable to var from the above statement
profile=var;
return new Forward( "success" );
}
Once you create and initialize your variables in the Page Flow, you can drag and drop the variables onto a JSP file. When you drag and drop an XMLBean variable onto a JSP File, Workshop displays the repeater wizard to guide you through the process of selecting the data you want to display. The repeater wizard provides choices for displaying the results in an HTML table or in a list.
Perform the following to add a NetUI repeater tag (used to display the data from a Liquid Data query) to a JSP file.
Note: You can only drag and drop leaf nodes from the Page Flow Properties.
Figure 2-19 Repeater Wizard Select Format Screen
You can create repeater tags inside of other repeater tags. You can display nested repeaters on the same page (in nested tables, for example) or you can set up Page Flow actions to display the nested level on another page (with a link, for example).
Perform the following steps to create a nested repeater tag.
Perform the following steps to add code in your JSP file to handle null values for your data. It is a common JSP design pattern to add conditional code to handle null values. If you do not handle null values, your page will display tag errors if it is rendered before the queries on it are executed.
<netui-data:repeater dataSource="{pageFlow.promo}" defaultText="no data">
defaultText attribute does not work for your netui-data:repeater tag, add code before and after the tag to test for null values. The following is sample code. The code in bold is added, the rest is generated by the repeater wizard. This code uses the profile variable initialized in To Initialize the Variable in the Page Flow.<%
PageFlowController pageFlow = PageFlowUtils.getCurrentPageFlow(request);
if ( ((pF2Controller)pageFlow).profile == null
|| ((pF2Controller)pageFlow).profile.getPROFILEVIEW().getCUSTOMERPROFILEArray() == null
|| ((pF2Controller)pageFlow).profile.getPROFILEVIEW().getCUSTOMERPROFILEArray().length == 0){
%>
<p>No data</p>
<% } else {%>
<netui-data:repeater dataSource=
"{pageFlow.profile.PROFILEVIEW.CUSTOMERPROFILEArray}">
<netui-data:repeaterHeader>
<table cellpadding="2" border="1" class="tablebody" >
<tr>
<!- the rest of the table and NetUI code goes here -->
<td><netui:label value
="{container.item.PROFILE.DEFAULTSHIPMETHOD}"></netui:label></td>
</tr>
</netui-data:repeaterItem>
<netui-data:repeaterFooter></table></netui-data:repeaterFooter>
</netui-data:repeater>
<% }%>
This section describes security considerations to be aware of when developing applications using Liquid Data controls. The following sections are included:
The WebLogic Workshop Application Properties (Tools —> Application Properties) allow you to set the connection information to connect to the domain in which you are running. You can either use the connection information specified in the domain boot.properties file or override that information with a specified username and password.
When you create a Liquid Data Control (.jcx) file and are connecting to a local Liquid Data server (Liquid Data on the same domain as Workshop), the user specified in the Application Properties is used to connect to the Liquid Data server. When you create a Liquid Data Control and are connecting to a remote Liquid Data server (Liquid Data on a different domain from Workshop), you specify the connection information in the Liquid Data Control Wizard Connection information dialog (see Figure 2-6).
When you create a Liquid Data Control, the Control Wizard displays all queries to which the specified user has access privileges. The access privileges are defined by any security policies set on the queries, either directly or indirectly.
Note: The security credentials specified through the Application Properties or through the Liquid Data Control Wizard are only used for creating the Liquid Data Control (.jcx) file, not for testing queries through the control. To test a query through the control, you must get the user credentials either through the application (from a login page, for example) or by using the run-as property in the Web Service file.
For testing, you can use the run-as property to test a control running as a specified user. To set the run-as property in a Web Service, open the Web Service and enter a user for the run-as property in the WebLogic Workshop property editor. Queries run through a Liquid Data Control used by the Web Service
When a query is run from an application, the application must have a mechanism for getting the security credential. The credential can come from a login screen, it can be hard-coded in the application, or it can be imbedded in a J2EE component (for example, using the run-as property in a .jws Web Service file).
Note: The Liquid Data Control property editor shows a run-as property, but the run-as property in the Liquid Data Control does not cause the Liquid Data Control to run as the specified user. If you want to use this feature, you must specify the run-as property in the .jws file, not in the .jcx file.
If the Liquid Data server is on different domain from WebLogic Workshop, then both domains must be set up as trusted domains.
Domains are considered trusted domains if they share the same security credentials. With trusted domains, a user that exists on one domain need not be authenticated on the other domain (as long as the user exists on both domains).
Note: After configuring domains as trusted, you must restart the domains before the trusted configuration takes effect.
Perform the following steps to configure domains as a trusted:
Figure 2-20 Setting up Trusted Domains
For more details on WebLogic security, see Configuring Security for a WebLogic Domain in the WebLogic Server documentation.
When you move any Liquid Data deployment from development to production, you must move Liquid Data and WebLogic Server resources (JDBC Connection Pools, Liquid Data Data Sources, the Liquid Data repository, and so on) from the development environment to the production environment. For details about deploying Liquid Data, see the Liquid Data Deployment Guide.
For applications that use Liquid Data controls, you must also deploy and update the ldcontrol.properties file, which contains connection information for Liquid Data controls. This section describes the development to production lifecycle and provides the basic steps for moving an application containing Liquid Data controls from development to production. The following sections are included:
In a typical development scenario, you will develop your applications in one environment and then deploy them in another. There are two main artifacts that you need to deploy on the production environment:
Figure 2-21 Development to Production Lifecycle
After you have developed and tested your application using WebLogic Workshop in your development environment, you must create a .ear file for deployment to your production server(s). All the resources the application needs are already included in the application Libraries directory, so the only thing you need to do is create the .ear file for the application.
Perform the following steps to generate an enterprise archive file (.ear) in WebLogic Workshop:
When the build is complete, WebLogic Workshop lists the .ear file location in the Build window.
Each domain that runs Liquid Data Control applications has a single ldcontrol.properties file, which stores the connection information for all Liquid Data Control applications running in the domain. The ldcontrol.properties file is located at the root directory of your domain where the Liquid Data Control application .ear file is deployed. There is an entry in the ldcontrol.properties file for each control you have created in each application.
The entries in the ldcontrol.properties file are of the following form:
AppName.ProjectName.FolderName.jcxName=t3\://hostname\:port
Note: The colons (:) in the URL must be escaped with a backslash (\) character.
If the URL value is missing, the Liquid Data Control uses the connection information from the domain config.xml file.
The following is a sample ldcontrol.properties file.
#Fri Oct 31 15:30:36 PST 2003
myTest.myTestWeb.myFolder.Untitled=t3\:myLDServer\:7001
myTest.myTestWeb.myFolder.myControl=
SampleApp.LiquidDataSampleApp.Controls.RTLControl=t3\:myLDServer\:7001
SampleApp.Untitled.NewFolder.Untitled=t3\:yourLDServer\:7001
testnew.Untitled.NewFolder.ldc=
test.testWeb.NewFolder.Untitled=
This section describes the following basic steps for moving an application from development to production:
Use WebLogic Workshop to generate the .ear file for your application as described in To Generate the .ear File in Workshop.
Merge the entries in the ldcontrol.properties file from the root level of your development domain with the ldcontrol.properties file in the root level of the production domain. There must be one entry for each Liquid Data Control. If the ldcontrol.properties file does not exist in the production domain, copy it from your development domain.
You must also update the URLs in each entry of the file to reference the production Liquid Data servers. For details on and for the syntax of the ldcontrol.properties file, see Liquid Data ldcontrol.properties File.
Deploy your enterprise archive (.ear) file on the production WebLogic Server. You deploy the .ear file from the domain —> Deployments —> Applications node of the WebLogic Server Administration Console. The .ear file must be accessible from the filesystem in which the WebLogic administration server is running. For details on deploying .ear files, see Deploying WebLogic Server Applications from the WebLogic Server documentation.
|
|
|
