<?xml version="1.0" encoding="utf-8"?>
<ManualTopic ID="/baanerp/da/onlinemanual/trg_to_set_up_triggering" xml:lang="en">
	<Header>
		<Title xmlns:HTML="http://www.w3.org/TR/REC-html40">To set up triggering</Title>
		<Keyword ContextSensitive="No"><Level1>Triggering</Level1>
			<Level2>Set-up</Level2>
		</Keyword>
		<Keyword ContextSensitive="No"><Level1>i-Flow</Level1>
		</Keyword>
	</Header>
	<GeneralSection><SectionTitle>Overview</SectionTitle>
		<GeneralSection><SectionTitle>Preparations</SectionTitle>
			<Paragraph class="Default">Before you set up triggering, you must specify the requirements/design. Consider what must happen and when. For example, if a new sales order is created in ERP LN, application X must be notified. Or, if a specific status field receives the value <GUIRef href="" role="manual">Active</GUIRef>, application Y must be notified.</Paragraph>
			<Paragraph class="Default">In addition, you must make clear what information must be communicated. In other words, what must be the content of the event message? For example, only an order number or other attributes from an order such as an order date or Sold-to Business Partner (customer) ID.</Paragraph>
			<Paragraph class="Default">Choose how to implement the triggering, for example, by means of Exchange or by means of an application customization. In addition, you must define the action to be carried out.</Paragraph>
			<Paragraph class="Default">While you specify these settings, you must consider performance-related questions. For example, how long must the process take before the target application is notified of an event? How frequently will events occur?</Paragraph>
			<Paragraph class="Default">Subsequently, you can perform the actual implementation.</Paragraph>
		</GeneralSection>
		<GeneralSection><SectionTitle>Overview of the actual implementation</SectionTitle>
			<ProcedureList><ListIntro>The process to implement triggering consists of the following steps:</ListIntro>
				<ListItem>Configure a trigger source, such as an exchange scheme or an application customization. For more information, refer to "To set up a trigger source," later in this chapter.</ListItem>
				<ListItem>Define the trigger, including the conditions and action. For more information, refer to "To define a trigger," later in this chapter.</ListItem>
				<ListItem>Test the trigger: start the required processes and manage the processes at runtime. For more information, refer to "Runtime tasks," later in this chapter.</ListItem>
			</ProcedureList>
		</GeneralSection>
	</GeneralSection>
	<GeneralSection><SectionTitle>To set up a trigger source</SectionTitle>
		<GeneralSection><SectionTitle>Trigger sources</SectionTitle>
			<List><ListIntro>As described previously, you can generate an event in multiple ways, including the following:</ListIntro>
				<ListItem>Application-based: Customize Infor ERP LN 6.1 to generate trigger events.</ListItem>
				<ListItem>Exchange-based: Use the Exchange module to collect the changed database rows or a complete set of database rows from one or more tables.</ListItem>
				<ListItem>Timer-based: Generate an event regularly according to a time interval or calendar.</ListItem>
			</List>
		</GeneralSection>
		<GeneralSection><SectionTitle>Application-based triggering</SectionTitle>
			<Paragraph class="Default">In the application, add a piece of code that generates an event message and invokes a trigger. You can attach this code, for example, to a library or to a program script.</Paragraph>
			<List><ListIntro>The following two APIs are available to attach this code:</ListIntro>
				<ListItem>API functions to create events are available in the <Emphasis>datrgevent</Emphasis> library.</ListItem>
				<ListItem>The API function to invoke a trigger is available in the <Emphasis>datrgapi</Emphasis> library.</ListItem>
			</List>
			<Paragraph class="Default">For detailed information, refer to the specifications of these libraries.</Paragraph>
			<Note><SectionTitle>
                                    Note
                                 </SectionTitle>
				<Paragraph class="Default">You can retrieve the library specifications from the library objects. At operating-system level, use explode6.2 to locate the library object, and subsequently use bic_info6.2 with the <GUIRef href="" role="manual">-eu</GUIRef> options.</Paragraph>
			</Note>
			<Paragraph class="Default">For example:</Paragraph>
			<Paragraph class="Default"><Code>$ explode6.2 odatrgevent</Code>
			</Paragraph>
			<Paragraph class="Default"><Code>/mybse/application/myvrc/odatrg/otrgevent</Code>
			</Paragraph>
			<Paragraph class="Default"><Code>$ bic_info6.2 -eu /mybse/application/myvrc/odatrg/otrgevent</Code>
			</Paragraph>
			<Paragraph class="Default">This command shows the documentation of the event handling functions.</Paragraph>
			<Paragraph class="Default">This method provides the prototypes, including the function name and type and parameters and their types, of the functions in the library, a description of the functions and their input and output, and the preconditions and post-conditions.</Paragraph>
			<Paragraph class="Default">The following is an example that shows how you can create an event from an application customization and to execute a trigger:</Paragraph>
			<CodeBlock space-and-orientation="indented-estimated">#pragma used dll odatrgevent    |event handling functions
#pragma used dll odatrgapi  |triggering api

#define CHECK_RETURN(retval)    if retval &lt;&gt; 0 then
^                                 ... |implementation depending|on context
^                               endif

long    my.event                |XML event used for triggering
long    retl                    |return value to be checked
string  exception.message(512) mb   |message if an error occurs
string  exception.details(512) mb   |details on exception message

if curr.inventory.on.hand &lt; threshold.value and prev.inventory.on.hand &gt;= threshold.value
then
    |low inventory, invoke trigger
    retl = datrgevent.simpleevent.create("Inventory", "LowInventory", my.event)
    CHECK_RETURN(retl)
    retl = datrgevent.simpleevent.set.value(my.event, "item", curr.item)
    CHECK_RETURN(retl)
    retl = datrgevent.simpleevent.set.value(my.event, "warehouse", curr.warehouse)
    CHECK_RETURN(retl)
    retl = datrgevent.simpleevent.set.value(my.event, "inventoryOnHand", 
                        curr.inventory.on.hand)
    CHECK_RETURN(retl)
    retl = datrgevent.simpleevent.set.old.value(my.event, "inventoryOnHand", 
                        prev.inventory.on.hand)
    CHECK_RETURN(retl)
    retl = datrgapi.trigger.do("mytrigger", my.event, exception.message, exception.details)
    CHECK_RETURN(retl)
endif</CodeBlock>
			<Paragraph class="Default">The simple event functions are offered to create events that consist of only one component. Specifying a class name (entity), event type (action), and the attribute name and value for each attribute is sufficient. In addition, if desired, you can also add the previous attribute value. Other event functions are available to create more complex events, such as multilevel events that consist of header and line components. For more information, refer to Chapter 3, "Event handling."</Paragraph>
		</GeneralSection>
		<GeneralSection><SectionTitle>Exchange-based triggering (changes)</SectionTitle>
			<Paragraph class="Default">To use Exchange-based triggering, you must define an exchange scheme, including ASCII file and fields, batch, table relations (export), and field relations (export). In case of triggering, the ASCII file and fields might not be relevant in the sense that no physical ASCII files are created. However, these files and fields are relevant because they define the contents of the event. The ASCII file represents the object (or component) and the fields represent the attributes included in the event.</Paragraph>
			<Paragraph class="Default">The mapping of the event, and the event’s required attributes, to the table and columns must be made clear. If a one-to-one mapping exists between columns and required attributes for the trigger, the exchange scheme can largely be generated as described in the following procedure. If required, you can add constant or calculated values to the output. Note that for calculated/transformed values, scripting is required.</Paragraph>
			<ProcedureList><ListIntro>You can easily set up an exchange scheme in the following way:</ListIntro>
				<ListItem>In the <GUIRef href="/baanerp/da/xch/daxch0501m000" role="session">Exchange Schemes (daxch0501m000)</GUIRef> session, create the main entity and define the exchange scheme attributes.</ListItem>
				<ListItem>In the <GUIRef href="/baanerp/da/xch/daxch0501m000" role="session">Exchange Schemes (daxch0501m000)</GUIRef> session, on the <GUIRef href="" role="manual">Specific</GUIRef> menu, click <GUIRef href="/baanerp/da/xch/daxch0501m000#daxch0102m000" role="command">ASCII Files</GUIRef> to start the <GUIRef href="/baanerp/da/xch/daxch0102m000" role="session">ASCII Files (daxch0102m000)</GUIRef> session.</ListItem>
				<ListItem>While you use a table code for the ASCII file, create a new ASCII file. You can leave the <GUIRef href="/baanerp/da/xch/daxch0102m000#daxch002.deff" role="manual">Definition File</GUIRef> field empty. If multiple tables are required, create multiple entries.</ListItem>
				<ListItem>On the <GUIRef href="" role="manual">Specific</GUIRef> menu, click <GUIRef href="/baanerp/da/xch/daxch0102m000#exec.user.0" role="command">Create ASCII Files...</GUIRef> to start the <GUIRef href="/baanerp/da/xch/daxch0203m000" role="session">Create ASCII File Fields and Relations (daxch0203m000)</GUIRef> session.</ListItem>
				<ListItem>Choose the required range of ASCII files.</ListItem>
				<ListItem>Make sure the following check boxes are selected: <List><ListItem><GUIRef href="/baanerp/da/xch/daxch0203m000#from.trit" role="manual">Create Based on Table Definitions</GUIRef>
						</ListItem>
						<ListItem><GUIRef href="/baanerp/da/xch/daxch0203m000#cbat.yn" role="manual">Create Batch</GUIRef>. Enter the code and description of the batch to be created in the fields that correspond to the check box.</ListItem>
						<ListItem><GUIRef href="/baanerp/da/xch/daxch0203m000#exp.rel" role="manual">Create Export Relations</GUIRef>
						</ListItem>
					</List>
				</ListItem>
				<ListItem>Start the process, which now generates the required exchange scheme contents.</ListItem>
				<ListItem>Remove any unwanted fields by deleting the corresponding rows from the <GUIRef href="/baanerp/da/xch/daxch0531m000#daxch0532m000" role="command">Field Relations (Export)</GUIRef> session and from the <GUIRef href="/baanerp/da/xch/daxch0503m000" role="session">ASCII File Fields (daxch0503m000)</GUIRef> session.</ListItem>
			</ProcedureList>
			<Paragraph class="Default">After the exchange setup is complete, you can run the <GUIRef href="/baanerp/da/xch/daxch0228m000" role="session">Create Export Programs (daxch0228m000)</GUIRef> session to create a runtime program that implements the settings as defined in exchange scheme.</Paragraph>
			<Paragraph class="Default">For more information on Exchange, refer to the Web Help.</Paragraph>
			<Paragraph class="Default">The exchange scheme must be based on audit. Therefore you must generate an audit configuration for the tables in the exchange scheme. Use the <GUIRef href="/baanerp/da/xch/daxch1201m000" role="session">Generate Audit Configuration (daxch1201m000)</GUIRef> session for this. For more information on Audit Management, refer to the Web Help.</Paragraph>
			<Paragraph class="Default">After you set up the exchange scheme and the triggers, you must define the relation between the two. In other words, one or more triggers must be linked to the exchange scheme. To link these triggers, you must use the <GUIRef href="/baanerp/da/xch/daxch0135m000" role="session">Export Triggers (daxch0135m000)</GUIRef>. For details on this session, refer to the Web Help.</Paragraph>
		</GeneralSection>
		<GeneralSection><SectionTitle>Exchange-based triggering (full export)</SectionTitle>
			<Paragraph class="Default">If a complete data set must be published regardless of what data was created, deleted, or changed, you can use a full exchange export.</Paragraph>
			<List><ListIntro>In this case, the setup is the same as described in "Exchange-based triggering (changes)," later in this chapter, with the following exceptions:</ListIntro>
				<ListItem>The exchange scheme must not be based on audit.</ListItem>
				<ListItem>No audit setup is required.</ListItem>
			</List>
		</GeneralSection>
		<GeneralSection><SectionTitle>Timer-based triggering</SectionTitle>
			<Paragraph class="Default">No specific setup is required for timer-based triggering. You must define the trigger as described in "To define a trigger," later in this chapter. Subsequently, you can start the process as described in "Runtime tasks," later in this chapter.</Paragraph>
		</GeneralSection>
	</GeneralSection>
	<GeneralSection><SectionTitle>To define a trigger</SectionTitle>
		<Paragraph class="Default">In the Triggering module, you must define the trigger, including the trigger’s conditions and actions, as required. You can create triggers in the <GUIRef href="/baanerp/da/trg/datrg1100m000" role="session">Triggers (datrg1100m000)</GUIRef> session. This session contains a configuration interface that enables you to generate the condition and action logic. Note that you can use the same trigger for multiple types of events, and even from multiple sources.</Paragraph>
		<Paragraph class="Default">If applicable, you can define conditions for the trigger. A condition limits the number of events for which a trigger action is performed. You can define conditions by means of the <GUIRef href="/baanerp/da/trg/datrg1110m000" role="session">Configure Trigger Conditions (datrg1110m000)</GUIRef> session. In this session, you can create or update conditions on class, event type, or attribute value.</Paragraph>
		<Paragraph class="Default">If the functionality available in this session is insufficient for the condition you want to create, you can attach a script that contains complex conditions. For details, refer to the "Configure attached condition script" online manual topic.</Paragraph>
		<List><ListIntro>In addition, you must define an action for the trigger. The type of action that you must define depends on the action template that you select for the trigger:</ListIntro>
			<ListItem>A <Emphasis>Fan Out Action</Emphasis> Use this action template if the trigger must invoke multiple actions (subsequent triggers) in parallel.</ListItem>
			<ListItem>An <Emphasis>XML File Action</Emphasis> Contains the settings in case the trigger must act by creating a file containing the event.</ListItem>
			<ListItem>If the user interface functionality is insufficient to meet the requirements, the user can implement a specific configuration by attaching code (a script) that implements the trigger action. For details, refer to the "Configure attached action script" online manual topic.</ListItem>
		</List>
		<Paragraph class="Default">If you define a trigger, the runtime program is automatically generated. The program is also regenerated automatically when you change the trigger, or the trigger’s conditions or action. In addition, you can click <GUIRef href="/baanerp/da/trg/datrg1100m000#exec.user.3" role="command">Generate Program</GUIRef> in the <GUIRef href="/baanerp/da/trg/datrg1100m000" role="session">Triggers (datrg1100m000)</GUIRef> session to regenerate the runtime program.</Paragraph>
	</GeneralSection>
	<GeneralSection><SectionTitle>Runtime tasks</SectionTitle>
		<GeneralSection><SectionTitle>Overview</SectionTitle>
			<Paragraph class="Default">At runtime, the following happens: The triggering module offers an interface to initiate a trigger. Input in that case is an XML structure describing the event. The user can call this interface from the Exchange module, from an application, or from the <GUIRef href="/baanerp/da/trg/datrg1200m000" role="session">Start Triggering via Job Timer (datrg1200m000)</GUIRef> session. If you do not invoke this interface from an application or exchange process, the process checks whether an action is defined for the specified trigger and runs the corresponding trigger function.</Paragraph>
			<Paragraph class="Default">The following subsections describe how to manage the process at runtime.</Paragraph>
		</GeneralSection>
		<GeneralSection><SectionTitle>Trigger management</SectionTitle>
			<Paragraph class="Default">For the trigger itself: no further action is required. The trigger is passive. Therefore, the trigger simply waits until one of the trigger sources invokes the trigger. If the trigger does not act as desired, you can debug the trigger. For more information, refer to the <GUIRef href="/baanerp/da/trg/datrg1100m000" role="session">Triggers (datrg1100m000)</GUIRef> session online Help.</Paragraph>
			<Note><SectionTitle>
                                    Note
                                 </SectionTitle>
				<Paragraph class="Default">If a trigger does not exist, this will not be reported as an error. For example, assume that an application can run in multiple companies and only from one company must something be done upon a trigger. In this case, the same application can run if the trigger is only defined in one company.</Paragraph>
			</Note>
		</GeneralSection>
		<GeneralSection><SectionTitle>Application-based triggering</SectionTitle>
			<Paragraph class="Default">For application-based triggering, no action is required at runtime either. The trigger invocation is included in the application logic, therefore, the trigger invocation will be performed automatically when the corresponding application state is reached.</Paragraph>
		</GeneralSection>
		<GeneralSection><SectionTitle>Exchange-based triggering</SectionTitle>
			<Paragraph class="Default">To use exchange-based triggering, the export process must be running regularly. You can add the <GUIRef href="/baanerp/da/xch/daxch0234m000" role="session">Export Data (on a Regular Basis) (daxch0234m000)</GUIRef> session to a job that runs according to a calendar or a predefined time interval.</Paragraph>
			<Paragraph class="Default">This job ensures that the exchange scheme regularly picks up the changes from the audit trail or the data from the database tables and invokes the corresponding triggers. For details, refer to the Exchange online Help.</Paragraph>
			<Paragraph class="Default">Bear in mind that in practice, the time interval must not be shorter than the time the export process requires to be completed successfully. If a small interval, such as one minute or a few minutes, is required, check beforehand whether the selected interval is feasible. Note that the duration of the export process depends heavily on the amount of changes or data to be processed and the trigger action defined.</Paragraph>
			<Paragraph class="Default">You must run all normal management activities required to run an exchange scheme. For example, occasionally, you might want to clean up data produced by the export process. Exchange offers logging facilities to check whether the process is running successfully.</Paragraph>
			<Paragraph class="Default">If you use the audit mechanism to detect change events, the audit trail must be cleaned up regularly, if the data is no longer required.</Paragraph>
			<Paragraph class="Default">Finally, note that the audit setup impacts performance. If the system sizing is correct and the audit is configured properly, the impact will be minimal, because the overhead is usually not greater than a few percent. Locating the audit data on a disk that is not a potential bottleneck is strongly advised. In addition, you can deploy disk striping to improve performance.</Paragraph>
		</GeneralSection>
		<GeneralSection><SectionTitle>Timer-based triggering</SectionTitle>
			<Paragraph class="Default">Run the <GUIRef href="/baanerp/da/trg/datrg1200m000" role="session">Start Triggering via Job Timer (datrg1200m000)</GUIRef> session to regularly generate a predefined event. Refer to the Web Help for details.</Paragraph>
		</GeneralSection>
		<GeneralSection><SectionTitle>Target application</SectionTitle>
			<Paragraph class="Default">Finally, the application that receives the event will require attention. For example, this application must clean up received files after processing.</Paragraph>
		</GeneralSection>
	</GeneralSection>
	<GeneralSection><SectionTitle>Exchange-specific limitations</SectionTitle>
		<Paragraph class="Default">The following limitations apply to Exchange-based triggering.</Paragraph>
		<GeneralSection><SectionTitle>Table vs. business object level</SectionTitle>
			<Paragraph class="Default">If you use events from Exchange, the triggers will be defined at table level rather than at Business Object level. Information from other tables can be included (scripting options are available), however, this requires programming. Note, however, that if the primary key of the object is the only attribute that is required, the same event can be generated from multiple tables. For example, a change on an order header and a change on an order line can both result in the same event, if required.</Paragraph>
			<Paragraph class="Default">An example of an event that cannot be defined without programming a so-called condition script in the exchange scheme is as follows: "Initiate an approval process if the quantity of an order line is changed and the status of the order header is Open".</Paragraph>
		</GeneralSection>
		<GeneralSection><SectionTitle>Unchanged table fields</SectionTitle>
			<Paragraph class="Default">If a row is created in or deleted from a table, the event generated by the Exchange export includes all ASCII fields as defined. However, if a row is changed, by default only the primary key fields and the changed fields will be included.</Paragraph>
			<Paragraph class="Default">For example, if you handle events on or order line consisting of an order number, line number, item, quantity and price, if the price is changed, the item and quantity will not be available in the event. You must take this into account when you define the trigger and when you process the event in the application that finally receives trigger. A trigger condition on quantity will only be met if the quantity is available; in other words, if the row is created or deleted, or if the quantity value is changed.</Paragraph>
			<Paragraph class="Default">To change this default behavior, you must change the audit type of the table fields in your exchange scheme’s audit profile.</Paragraph>
			<List><ListIntro>Two audit types exist:</ListIntro>
				<ListItem><GUIRef href="" role="manual">Always</GUIRef>: The field is logged each time when the content of the field, or the content of any other audited field, changes. This is the default setting for all primary key fields.</ListItem>
				<ListItem><GUIRef href="" role="manual">Changed</GUIRef>: The field is logged only when the content of the field itself changes. This is the default setting for all fields that do not belong to the primary key.</ListItem>
			</List>
			<ProcedureList><ListIntro>To make sure that a table field is always logged in the audit trail, you must change the field’s audit type to "Always". To do so, take the following steps:</ListIntro>
				<ListItem>Start the <GUIRef href="/baanerp/tt/aud/ttaud3110m000" role="session">Audit Profiles (ttaud3110m000)</GUIRef> session and select the audit profile that belongs to your exchange schema (the audit profile that you generated through the <GUIRef href="/baanerp/da/xch/daxch1201m000" role="session">Generate Audit Configuration (daxch1201m000)</GUIRef> session).</ListItem>
				<ListItem>Click <GUIRef href="/baanerp/tt/aud/ttaud3110m000#table.settings" role="command">Table Settings by Profile</GUIRef> on the <GUIRef href="" role="manual">Specific</GUIRef> menu. The <GUIRef href="/baanerp/tt/aud/ttaud3120m000" role="session">Audit Tables by Profile (ttaud3120m000)</GUIRef> session is started. A list of tables is displayed.</ListItem>
				<ListItem>Select the table for which you want to change the audit settings, and click <GUIRef href="/baanerp/tt/aud/ttaud3120m000#table.fields" role="command">Audit Fields by Table</GUIRef> on the <GUIRef href="" role="manual">Specific</GUIRef> menu. The <GUIRef href="/baanerp/tt/aud/ttaud3125m000" role="session">Audit Fields by Table (ttaud3125m000)</GUIRef> session is started. In this session you can change the audit type per table field. You can select the desired audit type (for example,. "Always") from the list.</ListItem>
				<ListItem>Run the <GUIRef href="/baanerp/tt/aud/ttaud3200s000" role="session">Create Runtime Audit Definitions (ttaud3200s000)</GUIRef> session to generate new runtime audit definitions. You can start this session via the <GUIRef href="" role="manual">Specific</GUIRef> menu in the <GUIRef href="/baanerp/tt/aud/ttaud3110m000" role="session">Audit Profiles (ttaud3110m000)</GUIRef> session.</ListItem>
				<ListItem>Restart your virtual machine (bshell).</ListItem>
			</ProcedureList>
			<Note><SectionTitle>
                                    Note
                                 </SectionTitle>
				<Paragraph class="Default">For details about Audit Management, refer to the Web Help and to the <DocRef>Infor Enterprise Server 8.5 Technical Manual (U8172 US)</DocRef>.</Paragraph>
			</Note>
		</GeneralSection>
		<GeneralSection><SectionTitle>Event types</SectionTitle>
			<List><ListIntro>Only events that can be defined in terms of a change in persistent data can be handled. The event must be described in terms of the following:</ListIntro>
				<ListItem>Tables</ListItem>
				<ListItem>Event type (action): <List><ListItem>Create</ListItem>
						<ListItem>Change</ListItem>
						<ListItem>Delete</ListItem>
					</List>
				</ListItem>
				<ListItem>Attribute values.</ListItem>
			</List>
			<List><ListIntro>Examples of events that can be generated from Exchange based on audit include the following:</ListIntro>
				<ListItem>A new Item row is added.</ListItem>
				<ListItem>The quantity of an item row changes.</ListItem>
				<ListItem>The quantity of an item row is increased. Note that you cannot configure this condition directly in the triggering user interface. However, to configure this condition, you can customize the generated triggering implementation function, as described in the "Configure attached condition script" online manual topic.</ListItem>
				<ListItem>An item row with item group Hardware is created, changed, or deleted. However, as described previously, if an item row is changed, but the item group is not changed, the event will not meet the condition.</ListItem>
			</List>
			<List><ListIntro>Examples of events that <Emphasis>cannot</Emphasis> be generated from Exchange include the following:</ListIntro>
				<ListItem>An item row is changed by means of the <GUIRef href="" role="manual">abcde1234m000</GUIRef> session</ListItem>
				<ListItem>An item row is change by user <Emphasis>john</Emphasis>.</ListItem>
			</List>
		</GeneralSection>
		<GeneralSection><SectionTitle>Miscellaneous Exchange-specific limitations</SectionTitle>
			<List><ListItem>From Exchange, no (multiline) texts are included in the XML event. You can include text numbers.</ListItem>
				<ListItem>Events from Exchange use the ASCII file/field names as component/attribute names. This implies that the events will have a maximum of eight characters.</ListItem>
				<ListItem>Dates will be formatted according to the date format specified in the Exchange scheme properties in the <GUIRef href="/baanerp/da/xch/daxch0501m000" role="session">Exchange Schemes (daxch0501m000)</GUIRef> session, and/or ASCII file format properties in the <GUIRef href="/baanerp/da/xch/daxch0503m000" role="session">ASCII File Fields (daxch0503m000)</GUIRef> session.</ListItem>
				<ListItem>For enumerated constants, you must use the constant’s numeric value instead of the constant’s name. For example, in a trigger condition, you must use tdsls400.corg = 3 instead of tdsls400.corg = tdsls.corg.eop.</ListItem>
				<ListItem>No multibyte conversion is performed on multibyte string values stored in the XML event.</ListItem>
			</List>
		</GeneralSection>
	</GeneralSection>
</ManualTopic>
