You configure connector properties from Connector Configurator Express. Regardless of the integration broker, you also configure meta-objects to enable the connector to process different business objects differently.
A connector obtains its configuration values at startup. During a runtime session, you might want to change the values of one or more connector properties. Changes to connector properties can be:
To determine whether a property is dynamic or static, refer to the configuration utility for your integration broker.
Connectors have two types of configuration properties:
You must set the values of some of these properties before running the connector.
You use meta-objects to configure the following aspects of connector behavior:
For information on meta-objects, see Using JText connector meta-objects.
Standard configuration properties provide information that all connectors use. See Appendix A, Standard configuration properties for connectors for documentation of these properties.
Table 4 provides information specific to this connector about
configuration properties in Appendix A.
Table 4. Property Information Specific to This Connector
Property | Note |
---|---|
CharacterEncoding | Because this connector is Java-based, it does not use this property. |
Locale | Because this connector has been internationalized, you can change the value of this property. See release notes for the connector to determine currently supported locales. |
Connector-specific configuration properties provide information needed by the connector at runtime. They also provide a way of changing static information or logic within the connector without having to recode and rebuild the connector.
Table 5 lists the connector-specific configuration properties for
the connector. See the sections that follow for explanations of the
properties.
Table 5. Connector-specific configuration properties
Name | Possible values | Default value | Required? |
---|---|---|---|
ArchivingEnabled | true or false |
true |
Yes |
EventLog | Name and location of file |
event.log |
No |
EventRecovery | abort or retry |
retry |
Yes |
FTPPollFrequency | number of poll cycles |
No | |
GenerateTemplate | BOName |
No | |
OutputLog | File that registers the next sequence number for each incoming business object during request processing |
Output.Log |
No |
PollQuantity | Number of events processed
at each poll |
25 |
No |
Turns on archiving. If this property is set to true, the event file is archived in the archive directory with the specified extension. If this property is set to false, the event file is not archived. In this case, the connector deletes the file after sending all events to the integration broker. For more information, see Specifying event archiving.
The default value is true.
Provides file storage location for events that are generated by the connector. This file is located in the JText subdirectory in the connectors directory where the product is installed.
The default value is event.log.
Specifies recovery behavior. If this property is set to retry, the connector uses the event.log file to recover failed events. If this property is set to abort, the connector terminates when it encounters a failed event. For more information, see Event log file.
The default value is retry.
Determines how frequently the connector polls an FTP server measured in the number of standard poll cycles. For example, if PollFrequency is set to 10000, and FTPPollFrequency is set to 6, the connector polls the local event directory every 10 seconds and polls the remote directory every 60 seconds. The connector performs FTP polling only if you specify a value for this property. If FTPPollFrequency evaluates to 0 or blank, the connector does not perform FTP polling. By default it does not.
There is no default value for this property.
Enables the connector to generate a template for each supported business object after connector startup. The syntax for this property is BOName;BOName where the name of a specific business object is substituted for BOName. For example, to generate two templates, one for a Customer business object and one for an Item business object, specify Customer;Item. For more information, see Generating sample business objects for testing.
There is no default value for this property.
Specifies the name of the file that stores the sequence number that the connector uses to create unique output files for each type of business object during request processing. The format of the file is:
BusinessObjectName = NextSequenceNumber
where BusinessObjectName is the name of the request business object, and NextSequenceNumber represents the sequence number of the most recently received business object, incremented by one. For example, if the connector is processing Customer and Item business objects, the output log file might contain the following:
Customer = 12 Item = 2
This file indicates that the connector has already processed 11 Customers and 1 Item. The next Customer and Item business objects will be written to the Customer_12.out and Item_2.out files, respectively. When it receives a request Order business object, the connector adds a new row to the output log file and writes the business object to the Order_1.out file.
If FileSeqEnabled is set to true, the connector uses this sequence number to uniquely name the output files that it creates for each business object. The connector names each output file by appending an underscore (_) and the sequence number to the business object's name or to a file whose name is specified in the OutputFileName meta-object attribute. Because the output log is stored in user-readable format, you can use a standard text editor to read the file or to reset its value.
For more information on the OutputFileName attribute, see Specifying the name of the output file. For more information about the output log, see Specifying request processing. For information on returning the generated file's name, see Returning a file's name.
The default is Output.Log.
Specifies the number of events to process for each poll. The connector poll method retrieves the specified number of event records and processes them in a single poll. Processing multiple events per poll can improve performance when the application generates large numbers of events. However, because integration-broker requests are blocked while the poll method is processing events, do not set the number of events too high. If each poll call takes a long time, it delays integration-broker request operations. For more information, see Tuning the performance of the JText connector.