Specifying Components as Properties : ATG

The preceding examples demonstrated how Nucleus can create and initialize components from properties files. While this is itself a powerful function, the true power of Nucleus is its ability to allow components to point to each other through configuration files.

The easiest way to get components to point to each other is through properties. For example, say that a Weather component is defined in Nucleus, and the Person component needs a pointer to that Weather.

The Weather class might look like this:

public class Weather {
String currentWeather;

  public Weather () {
    System.out.println ("constructing Weather");
  }
  public String getCurrentWeather () {
    return currentWeather;
  }
  public void setCurrentWeather (String currentWeather) {
    System.out.println ("setting currentWeather to " + currentWeather);
    this.currentWeather = currentWeather;
  }
}

For this example, we need an instance of Weather in Nucleus, called /services/Weather. This means that you should compile the Weather Java class and create a Weather class component with a Weather.properties file in the same directory as Person.properties. Note that, as with any Nucleus component, you can create /services/Weather either with the ATG Control Center’s Generic Component Wizard, or by writing a properties file like this:

$class=Weather
currentWeather=sunny

Now modify the Person component to contain a property that points to the Weather:

public class Person {
  String name;
  int age;
  Weather weather;

  public Person () {
    System.out.println ("constructing Person");
  }
  public String getName () { return name; }
  public void setName (String name) {
    System.out.println ("setting name to " + name);
    this.name = name;
  }
  public int getAge () { return age; }
  public void setAge (int age) {
    System.out.println ("setting age to " + age);
    this.age = age;
  }
  public Weather getWeather () { return weather; }
  public void setWeather (Weather weather) {
    System.out.println ("setting weather to " + weather.getCurrentWeather ());
    this.weather = weather;
  }
}

Finally, the Person component must be modified so that it has a weather property that points to the weather component:

$class=Person
name=Stephen
age=20
weather=Weather

If you have included the Person component as an initial service (as described in the Starting a Nucleus Component section in this chapter), then, when you start your application, the Person component will be created and initialized. Its name and age properties will be set from the values found in the properties file. But to set the weather property, Nucleus must resolve the name Weather. In doing so, Nucleus ends up creating the Weather component and initializing that component before assigning it to the Person property. The output should look something like this:

constructing Person
setting age to 20
constructing Weather
setting currentWeather to sunny
setting weather to sunny
setting name to Stephen

The first two lines of the output show that Nucleus has created the /services/Person component and has set the age property. Then Nucleus attempts to set the weather property. In doing so, it searches for the component named Weather. This is a relative name, and so it is resolved relative to the current context /services, resulting in /services/Weather.

Nucleus searches its existing components and, finding that there is no /services/Weather, it attempts to create one from the configuration file found in services/Weather.properties. This causes Nucleus to construct an instance of the Weather class and initialize its currentWeather property, thereby resulting in the third and fourth lines of output.

Now that a /services/Weather component has been created and initialized, Nucleus can go on to initialize the rest of the Person component, by setting its weather and name properties. This results in the last two lines of output.

Nucleus does not put a “nesting limit” on the number of components that may refer to each other through properties. For example, component 1 may refer to component 2, may refer to component 3, etc. Nucleus also allows circular references. For example, component 1 may have a property that points to component 2, which may have a property that points back to component 1. In fact, component 1 may have a property that points back to itself. Nucleus handles these circular cases without spiraling into infinite loops.

Application errors can sometimes occur, however, if you reference a property of a component before that component is completely configured. To diagnose this type of error, set the loggingInfo property of the / Nucleus service to true, and the ATG platform will print information messages for this situation.

Arrays of components can also be specified in the same way that other array values are specified: as a comma-separated list. For example, the Person component may have a property called cityWeathers that contains an array of Weather components:

public Weather [] getCityWeathers ();
public void setCityWeathers (Weather [] cityWeathers);

This property might be initialized in the configuration file like this:

cityWeathers=\
        /services/weather/cities/atlanta,\
        /services/weather/cities/boston,\
        /services/weather/cities/tampa,\
        /services/weather/cities/phoenix

Nucleus handles this by finding each of the components in the list, arranging the found components into a 4-element array, then assigning that array to the cityWeathers property of the Person component.

DMS Configuration File Tags For Accessing DAF Schema : ATG

This contains the Document Type Definition (DTD) for DMS configuration files. The DTD describes all XML tags that can be used in a DMS configuration file.


<!--
This is the XML DTD for the PatchBay 1.0 configuration file.
-->

<!--
The dynamo-message-system element describes the configuration of all
the elements of the dynamo messaging system.  It describes the patch
bay, the local JMS configuration, and the message registry.
-->

<!ELEMENT dynamo-message-system (patchbay, local-jms,
message-registry)>


<!--
The patchbay element defines the configuration of the PatchBay
component of the dynamo messaging system.  It begins with a
declaration of the JMS providers used in the system, then declares
each message-source, message-sink, and message-filter managed by the
PatchBay.

Used in: dynamo-message-system
-->

<!ELEMENT patchbay (provider*, message-source*, message-sink*,
message-filter*)>


<!--
The provider element describes one JMS provider that will be used in
the Patch Bay.  It assigns a name to the provider, describes where the
various ConnectionFactory interfaces can be found, and includes flags
describing the provider's transaction capabilities.

Used in: patchbay
-->

<!ELEMENT provider (provider-name, topic-connection-factory-name?,
queue-connection-factory-name?, xa-topic-connection-factory-name?,
xa-queue-connection-factory-name?, supports-transactions?,
supports-xa-transactions?, username?, password?, client-id?,
initial-context-factory?)>


<!--
The provider-name assigns a name to a provider for use by destination
references in the file.

Used in: provider, input-destination, output-destination

Example:
<provider-name>MQSeries</provider-name>
-->

<!ELEMENT provider-name (#PCDATA)>


<!--
The topic-connection-factory-name describes the JNDI location of the
provider's TopicConnectionFactory interface.

Used in: provider

Example:
<topic-connection-factory-name>
  dynamo:/dms/local/LocalDMSManager
</topic-connection-factory-name>
-->

<!ELEMENT topic-connection-factory-name (#PCDATA)>


<!--
The queue-connection-factory-name describes the JNDI location of the
provider's QueueConnectionFactory interface.

Used in: provider

Example:
<queue-connection-factory-name>
  dynamo:/dms/local/LocalDMSManager
</queue-connection-factory-name>
-->

<!ELEMENT queue-connection-factory-name (#PCDATA)>


<!--
The xa-topic-connection-factory-name describes the JNDI location of
the provider's XATopicConnectionFactory interface.

Used in: provider

Example:
<xa-topic-connection-factory-name>
  dynamo:/dms/local/LocalDMSManager
</xa-topic-connection-factory-name>
-->

<!ELEMENT xa-topic-connection-factory-name (#PCDATA)>


<!--
The xa-queue-connection-factory-name describes the JNDI location of
the provider's XAQueueConnectionFactory interface.

Used in: provider

Example:
<xa-queue-connection-factory-name>
  dynamo:/dms/local/LocalDMSManager
</xa-queue-connection-factory-name>
-->

<!ELEMENT xa-queue-connection-factory-name (#PCDATA)>


<!--
The supports-transactions element indicates if the provider supports
transactions through the Session.commit()/rollback() methods.

Used in: provider

Must be one of:
<supports-transactions>true</supports-transactions>
<supports-transactions>false</supports-transactions>
-->

<!ELEMENT supports-transactions (#PCDATA)>


<!--
The supports-xa-transactions element indicates if the provider supports
transactions through the XA interface.

Used in: provider

Must be one of:
<supports-xa-transactions>true</supports-xa-transactions>
<supports-xa-transactions>false</supports-xa-transactions>
-->

<!ELEMENT supports-xa-transactions (#PCDATA)>


<!--
The username element specifies the username that should be
provided when creating a new connection.

Used in: provider

Example:
<username>
  charles
</username>
-->

<!ELEMENT username (#PCDATA)>


<!--
The password element specifies the password that should be
provided when creating a new connection.

Used in: provider

Example:
<password>
  charles
</password>
-->

<!ELEMENT password (#PCDATA)>


<!--
The client-id element specifies the client identifier that will be
assigned to the connection.  This is primarily used to reconnect to
durable subscription state.

Used in: provider

Example:
<client-id>
  OrderProcessor
</client-id>
-->

<!ELEMENT client-id (#PCDATA)>


<!--

The initial-context-factory element specifies the nucleus name of a
component that implements the
atg.dms.patchbay.JMSInitialContextFactory interface.  This nucleus
component will be called on to create an InitialContext whenever a
JNDI name needs to be resolved for the provider (i.e., when resolving
the JNDI name of a Topic/QueueConnectionFactory, or a Topic or a
Queue).  If no initial-context-factory is supplied, then the JNDI
names will be resolved against a "vanilla" InitialContext (i.e., one
created by calling "new InitialContext()").

Used in: provider

Example:
<initial-context-factory>
  /atg/jmsproviders/providerx/InitialContextFactory
</initial-context-factory>
-->

<!ELEMENT initial-context-factory (#PCDATA)>


<!--

The message-source element describes one MessageSource.  It specifies
its Nucleus name, and also describes each of the MessageSource's
output ports.

Used in: patchbay
-->

<!ELEMENT message-source (nucleus-name, output-port*)>


<!--
The nucleus-name element specifies the absolute name of a global
Nucleus component.

Used in: message-source, message-sink, message-filter

Example:
<nucleus-name>
  /atg/commerce/sources/EmailSource
</nucleus-name>
-->

<!ELEMENT nucleus-name (#PCDATA)>


<!--
The output-port element specifies how one of the output ports is
connected to possibly many destinations.

Used in: message-source, message-filter
-->

<!ELEMENT output-port (port-name?, output-destination*)>

<!--
The redelivery-port element specifies how one of the redelivery ports is
connected to possibly many destinations.

Used in: message-sink, message-filter
-->

<!ELEMENT redelivery-port (port-name?, output-destination*)>

<!--
The port-name element specifies the name of an input or output port.

Used in: output-port, input-port

Example:
<port-name>
  DEFAULT
</port-name>
-->

<!ELEMENT port-name (#PCDATA)>


<!--
The output-destination describes one Destination to which Messages
through an output port should be sent.  Each destination describes the
JMS provider through which the Message should be sent, the JNDI name
of the Destination, whether the Destination is a Topic or Queue, and
what options should be set on Messages on their way out.

Used in: output-port
-->

<!ELEMENT output-destination (provider-name?, destination-name,
destination-type, priority?, delivery-mode?)>


<!--
The destination-name element specifies the JNDI name of the
Destination

Used in: output-destination, input-destination

Example:
<destination-name>
  localjms:/local/dcs/PurchaseEvents
</destination-name>
-->

<!ELEMENT destination-name (#PCDATA)>


<!--
The destination-type element specifies the type of the Destination

Used in: output-destination, input-destination

Must be one of:
<destination-type>Topic</destination-type>
<destination-type>Queue</destination-type>
-->

<!ELEMENT destination-type (#PCDATA)>


<!--
The priority element specifies the JMSPriority that should be assigned
to all Messages going to this Destination through this output-port.
The priority should be between 0 and 9 (inclusive).

Used in: output-destination

Example:
<priority>8</priority>
-->

<!ELEMENT priority (#PCDATA)>


<!--
The delivery-mode element specifies the JMSDeliveryMode that should be
assigned to all Messages going to this Destination through this
output-port.

Used in: output-destination

Must be one of:
<delivery-mode>PERSISTENT</delivery-mode>
<delivery-mode>NON_PERSISTENT</delivery-mode>
-->

<!ELEMENT delivery-mode (#PCDATA)>


<!--
The message-sink element describes one MessageSink.  It specifies its
Nucleus name, and also describes each of the MessageSink's input
ports.

Used in: patchbay
-->

<!ELEMENT message-sink (nucleus-name, input-port*, redelivery-port*)>


<!--
The input-port element specifies how one of the input ports receives
Messages from possibly many destinations.

Used in: message-sink, message-filter
-->

<!ELEMENT input-port (port-name?, input-destination*)>


<!--
The input-destination element describes one Destination from which
Messages are received and attributed to this input-port.  Each
Destination describes the JMS provider from which the Message should
be received, the JNDI name of the Destination, whether the Destination
is a Topic or Queue, the message selector to be used, and whether
local messages should be received.

Used in: input-port
-->

<!ELEMENT input-destination (provider-name?, destination-name,
destination-type, durable-subscriber-name?, message-selector?,
no-local?, redelivery?)>

<!--
The redelivery element describes the configuration parameters used
for message redelivery during failure conditions. max-attempts defines
the maximum number of delivery attempts by Patch Bay to the input
destination. The delay interval (specified in msec) defines how long a
message should be delayed before a redelivery is attempted. Finally
if the maximum number of delivery attempts has been reached then
the message will be redirected to the output port named through
the failure-output-port element.

Used in: input-destination
-->

<!ELEMENT redelivery (max-attempts, delay, failure-output-port)>
<!ELEMENT max-attempts (#PCDATA)>
<!ELEMENT delay (#PCDATA)>
<!ELEMENT failure-output-port (#PCDATA)>

<!--
The message-selector element describes the filter that will restrict
the flow of Messages from this Destination.

Used in: input-destination

Example:
<message-selector>
  JMSType = 'atg.dcs.Purchase'
</message-selector>
-->

<!ELEMENT message-selector (#PCDATA)>


<!--
The durable-subscriber-name element specifies the name of the durable
subscription to which this should subscribe.  This may only be
specified for Topic Destinations.  If this is not specified, a durable
subscription will not be used.

Used in: input-destination

Example:
<durable-subscriber-name>
  orders
</durable-subscriber-name>
-->

<!ELEMENT durable-subscriber-name (#PCDATA)>


<!--
The no-local indicates whether Messages sent to this Topic by the same
Session should not be received.  If true, then such messages are
blocked, otherwise such messages are received.  This may only be
specified for Topic destinations.  Defaults to false if not specified.

Used in: input-destination

Must be one of:
<no-local>true</no-local>
<no-local>false</no-local>
-->

<!ELEMENT no-local (#PCDATA)>


<!--
The message-filter element describes one MessageFilter.

Used in: patchbay
-->

<!ELEMENT message-filter (nucleus-name, input-port*, output-port*,
redelivery-port*)>


<!--
The local-jms element configures the Local JMS system that will be
used with the patch bay in the dynamo messaging system.  It configures
the JNDI prefix that will be used for the destination names, and also
names all of the queues and topics in the Local JMS system.

Used in: dynamo-message-system
-->

<!ELEMENT local-jms (jndi-prefix, topic-name*, queue-name*)>


<!--
The jndi-prefix element specifies what JNDI prefix should be prepended
to each topic or queue name to form the destination's JNDI name.  The
prefix should start with "/" and should not include the "localdms:".
The destination's JNDI name will be
"localdms:{jndi-prefix}{topic/queue-name}".

Used in: local-jms

Example:
<jndi-prefix>
  /local
</jndi-prefix>
-->

<!ELEMENT jndi-prefix (#PCDATA)>


<!--
The topic-name element specifies the name of a Topic in the Local JMS
system.  The name should begin with a "/", and must be unique among
both topic-name and queue-name elements.

Used in: local-jms

Example:
<topic-name>
  /ProfileEvents
</topic-name>
-->

<!ELEMENT topic-name (#PCDATA)>


<!--
The queue-name element specifies the name of a Queue in the Local JMS
system.  The name should begin with a "/", and must be unique among
both queue-name and queue-name elements.

Used in: local-jms

Example:
<queue-name>
  /ProfileEvents
</queue-name>
-->

<!ELEMENT queue-name (#PCDATA)>


<!--
The message-registry element is the root element of the
MessageRegistry configuration file.  It defines several message-family
elements.

Used in: dynamo-message-system
-->

<!ELEMENT message-registry (message-family*)>


<!--
The message-family element describes a group of message-type elements,
and may also recursively contain a set of message-family elements.

Used in: message-registry, message-family
-->

<!ELEMENT message-family (message-family-name, message-family*,
message-type*)>


<!--
The message-family-name element specifies the name of a
message-family.

Used in: message-registry, message-family

Example:
<message-family-name>atg.dcs</message-family-name>
-->

<!ELEMENT message-family-name (#PCDATA)>


<!--
The message-typer element describes one MessageTyper.

Used in: message-type
-->

<!ELEMENT message-typer (nucleus-name)>

<!--
The message-type element describes one mapping from JMSType to Object
class.

Used in: message-family
-->

<!ELEMENT message-type (jms-type, message-class, message-typer?, message-context?,
                        display-name?, display-name-resource?, expert?, hidden?,
                        description?, description-resource?, resource-bundle?)>


<!--
The jms-type element specifies the JMSType for this message type.  The
jms-type must be unique across all message types in the message
registry.

Used in: message-type

Example:
<jms-type>
  atg.dcs.Purchase
</jms-type>
-->

<!ELEMENT jms-type (#PCDATA)>


<!--
The message-class element specifies the fully-qualified class name of
the Java Bean that contains the message's data.

Used in: message-type

Example:
<message-class>
  atg.dcs.PurchaseMessage
</message-class>
-->

<!ELEMENT message-class (#PCDATA)>


<!--
The message-context element specifies the nature of the message's
originating context.  If omitted, then no assumptions are made
concerning the message's context.  The following values are recognized:

   request: the message originates in a request thread, and
            request- or session-specific values may be resolved
    via JNDI.

   session: the message originates in a session-specific context, and
            session-specific values may be resolved via JNDI.
Used in: message-type

Example:
<message-context>
  request
</message-context>
-->

<!ELEMENT message-context (#PCDATA)>

<!--
The display-name element specifies a GUI display name for an element
described in the patch bay definition file.

Example:
<display-name>
  Buys Product
</display-name>
-->

<!ELEMENT display-name (#PCDATA)>

<!--
The display-name-resource element specifies a GUI display name for an element
described in the patch bay definition file, which can be loaded from a resource
bundle.

Example:
<display-name-resource>
  buysProduct
</display-name-resource>
-->

<!ELEMENT display-name-resource (#PCDATA)>

<!--
The description element specifies a GUI description for an element
described in the patch bay definition file.

Example:
<description>
  Generated when user purchases a product
</description>
-->

<!ELEMENT description (#PCDATA)>

<!--
The description-resource element specifies a GUI description for an element
described in the patch bay definition file, which can be loaded from a resource
bundle.

Example:
<description-resource>
  buysProductDescription
</description-resource>
-->

<!ELEMENT description-resource (#PCDATA)>

<!--
The resource-bundle element specifies a resource bundle from which resources
for an element described in the patch bay definition file can be loaded.

Example:
<resource-bundle>
  atg.dms.Resources
</resource-bundle>
-->

<!ELEMENT resource-bundle (#PCDATA)>

<!--
The hidden element specifies a flag indicating that the given message type
should be hidden in a GUI.

Example:
<hidden>
  true
</hidden>
-->

<!ELEMENT hidden (#PCDATA)>

<!--
The expert element specifies a flag indicating that the given message type
should be hidden in a GUI from non-expert users.

Example:
<expert>
  true
</expert>
-->

<!ELEMENT expert (#PCDATA)>

-----------------------------------------------------------------------------------------------------------------------

Creating Our Own ATG Dynamo Server Admin Interface

The Oracle ATG Web Commerce platform includes ATG Dynamo Server Admin, an HTML-based interface that lets you inspect individual components at runtime. The default interface displays a component by listing its contained children and the values of its properties. Individual components can override this default behavior and provide their own servlets to act as the interface for that component. These custom servlets can also subclass the default servlet, so that it looks like the normal default servlet, possibly with some additional information.

In order for a component to define a custom administration interface, it must implement atg.nucleus.AdminableService. When the administration interface is asked to display a particular component, it first checks to see if the component implements AdminableService. If it does, Nucleus calls getAdminServlet to get the servlet that displays the component’s administration interface, then passes the call off to that servlet. If the component does not implement getAdminServlet, Nucleus uses the default administrative servlet to display the component and its properties in the Component Browser.

The default administrative servlet is called atg.nucleus.ServiceAdminServlet. It contains a number of methods that can be overridden, as well as a number of methods that perform useful functions, such as formatting object values into HTML.

Creating Administration Servlets

GenericService already implements AdminServlet by creating an instance of ServiceAdminServlet when asked for the administration servlet. Subclasses of GenericService should override createAdminServlet.

 For example:


protected Servlet createAdminServlet ()
  {
    class AdminServlet extends ServiceAdminServlet {
      public AdminServlet (Object pService) {
        super (pService, getNucleus ());
      }

      protected void printAdmin (HttpServletRequest pRequest,
                                 HttpServletResponse pResponse,
                                 ServletOutputStream pOut)
           throws ServletException, IOException
      {
        pOut.println ("<h1>This is my special admin section</h1>");
      }
    }

    return new AdminServlet (this);
  }


This implementation uses an inner class that extends ServiceAdminServlet. The inner class overrides printAdmin to print out a line of HTML. The default servlet calls printAdmin to insert service-specific HTML between the listing of child components and the listing of property values. This is the easiest way for a service to provide its own administrative servlet.

Formatting Object Values

When a custom administrative servlet prints its output, you might want it to format object values into HTML output. The default administrative servlet ServiceAdminServlet provides a method that can be called by subclasses to do this formatting:

protected String formatObject (Object pObject,
                               HttpServletRequest pRequest);



This formatting method takes several steps to format the object:

1.It checks whether the object is a component that implements NameContextElement. If so, it  
   returns an anchor tag that contains a link to that component.

2.It checks whether the object implements atg.nucleus.ValueFormatter. If so, it calls the object’s
   formatValue() method and returns the result.

3.If the object is of type java.lang.Class, it returns an anchor tag that contains a link to the API
   documentation for that class.

4.If the object is of type java.lang.File, it returns an anchor tag that points to that file.

5.Otherwise, it uses the object’s toString() method.

The default administrative servlet uses this method to format the values of the properties that it displays.

ValueFormatter:

As mentioned above, objects can customize their HTML representations in ATG Dynamo Server Admin by implementing atg.nucleus.ValueFormatter. This interface has two methods:

public String formatValue ();
public String formatLongValue ();

If you use the Component Browser, you might notice that property values can take on two forms. In the main page that lists all properties, only the short form of the value is shown. But when you then click on the property, the property is shown to you in its own page. On this page, the long form of the value is shown.

For example, the short form of a Hashtable entry might simply declare that it is a Hashtable, while the long form might display all the keys and values in the Hashtable.

Functions of startSQLRepository: ATG

startSQLRepository Functions:

startSQLRepository, reads a repository definition from an XML file or DOM and


1. Verifies your XML is correctly formed and compliant with the DTD.

2. Parses and processes optional operation tags like <add-item>, <remove-item>, and <query-  
    items>. These tags provide a means for adding, removing, updating items in your SQL  \
    repository.

3. Generates SQL statements required to create appropriate table structure in database when you
    use the –outputSQL flag.

4. Returns results of <query-items> and <print-item> requests in the form of <add-item> tags.
    This allows you to easily copy and paste the results into another XML template, so you can add
    the items to another repository.

5. Imports and exports items and item descriptors

Using the startSQLRepository Script

Use one of the startSQLRepository scripts included in the <ATGdir>/home/bin directory:

If your template contains <table> tags, you must also make sure that:


1. the database accessed by your repository is running

2. the database contains the appropriate tables

3. you have appropriate database access authorization to perform any import or create database
    operations

you need to make sure that repository IDs in the source repository do not collide with repository IDs in the target repository. Make sure that both the source database and target database already contain IdSpaces. The IdSpaces in the source database and target database must have the same names. Furthermore, the name of the IdSpaces used by each item descriptor should be the same in the source repository for the export and the target repository for the import. If you do this, then the import operation reserves all the IDs it encounters for repository items it creates in the target database.

ID Generators should be happen and it will create idspaces.xml,

The startSQLRepository scripts use the following syntax:

startSQLRepository <arguments> [file name.xml]


For example, to load an XML template whose CONFIGPATH name is /atg/test.xml in a repository with a Nucleus address of /atg/userprofiling/ProfileAdapterRepository:

startSQLRepository -m DPS
   –repository /atg/userprofiling/ProfileAdapterRepository /atg/test.xml

Note that the repository template file name you provide is a reference to a CONFIGPATH location, and not a pathname in your file system. For example, you can put a file in your localconfig directory and refer to it as /<your-file>. You can also use a file with the same name as your repository’s existing definition file and then omit the file name argument from the startSQLRepository command. The startSQLRepository script uses XML file combination to combine all files with the same name into a single repository definition

if you include the following file at <ATGdir>/home/localconfig/atg/userprofiling/userProfile.xml and run the startSQLRepository script, it will print all profiles in your Profile Repository:

<gsa-template>
  <print-item item-descriptor="user"/>
</gsa-template>

You can use the startSQLRepository script together with the test operation tags described earlier in this chapter to quickly test a query, or add, update, remove, or print an item.

Exporting & Importing Data from SOLID : ATG

Exporting the CustomProject Data from SOLID:

Make sure that either there are no connection pool properties files, or that they are pointing to the CustomProject SOLID database. Start the SOLID database and use the commands below (on one line, with no line breaks) to export the demo data to an XML file called all.xml.

Command:

1. bin/startSQLRepository -m CustomProject -exportRepositories all all.xml

2. bin/startSQLRepository -m SampleProject -exportRepositories all all.xml

Importing the CustomProject Data to Your Database:

Your connection pool properties file must be pointing to the new target database. All Dynamo supported databases can import all.xml.

Oracle users: Before importing the CustomProject data, set the useSetCharacterStream property of all SQL repository components to true so that non-8859 characters are displayed correctly. You can set this property in your localconfig/GLOBAL.properties file: useSetCharacterStream=true

From the command line, go to the <ATGdir>/home directory. Use the commands below (on one line, with no line breaks) to import the data contained in all.xml to your target database. Your connection pool properties file must be pointing to the new target database.

Command:

1. bin/startSQLRepository -m CustomProject -import all.xml

2. bin/startSQLRepository -m  SampleProject -import all.xml


You can add your own project instead of CustomProject.