In the first article in this series, Getting connected – An introduction to connecting with adapters you learned the basics about using each type of resource adapter with WebSphere Integration Developer, including the difference between inbound and outbound processing and how resource adapters fit into your WebSphere Integration Developer application. In this article, we will look at how an application can read from (inbound processing) and write to (outbound processing) a file system using the IBM WebSphere Adapter for Flat Files. We will also show how to create a module using WebSphere Integration Developer that uses the WebSphere Adapter for Flat Files to read and write data files.
The term flatfile refers to any file stored on a file system, as opposed to a more complex set of files, such as those in a structured database. The data records in a flat file are typically stored sequentially and without any metadata, such as the indices, keys, and relationships that you would find in database storage. You can use the adapter for flat files to read and write any type of file. However, you typically use the adapter for flat files to read and write text files that store records in a flat file format such as XML or Comma-Separated Values (CSV) records. Figure 1 shows example records in each format.
Figure 1. Two flat files: XML(left) and CSV (right)
As you read in the first article in this series, you use a resource adapter to connect your application to an enterprise information system (EIS) in a standard way. The Enterprise Service Discovery wizard in WebSphere Integration Developer uses a resource adapter to discover services and business objects in an EIS, and then creates an export for inbound services and an import for outbound services. All you need is the resource adapter for your particular EIS.
You might have an EIS that outputs sets of files to a directory. An example might be an order processing system that produces files containing order information so that the orders can be processed in batch during off-peak hours. These files might store business information sequentially, not structured as business information would be in a relational database. The same or another information system might use sets of files in a directory as input to programs. You would use the WebSphere Adapter for Flat Files Version 6.0.2 to integrate this type of EIS into an application because it connects file systems and applications that run on an application server such as WebSphere Process Server or WebSphere Enterprise Service Bus.
Any WebSphere application can use the adapter for flat files to create and manage files or to monitor a directory and read files from this directory. Using the Enterprise Service Discovery wizard, you specify the directories that the WebSphere Adapter for Flat Files reads from and writes to, and the format of the data in those directories. The Enterprise Service Discovery wizard also creates any additional artifacts required, such as imports, exports, and the corresponding interfaces and business objects.
Inbound processing is the mode of operation in which the WebSphere Adapter for Flat Files monitors the file system, reads new files, and sends the data to the endpoint component.
Outbound processing is the mode of operation in which the WebSphere Adapter for Flat Files receives requests (from a component of a WebSphere application) to perform an operation on the enterprise information system and, when applicable, returns the results to the caller. Example operations include creating a file, writing to a file, or checking if a specific file exists.
During inbound processing, the adapter for flat files listens for events that are produced by an external EIS. An event is a record of what changes have occurred in the event directory. The directory that the adapter for flat files monitors for new files (the one that the EIS outputs its files to) is called the event directory.
Figure 2 shows the four steps that occur during inbound processing:
The EIS outputs its files to the event directory.
The adapter for flat files polls for files from the event directory and converts the data from those files into events. The adapter can be configured to poll for only certain types of files, or for files created during a certain time period.
Events are temporarily placed in an event store database. This database enables data persistence so that events will not be lost before your application can process them if the server goes down after an event is created, for example. When all events are stored in the database, the original file is deleted from the event directory.
- The adapter for flat files retrieves the events from the event store and passes each event in the form of a business object through an exported inbound interface, which the Enterprise Service Discovery wizard created.
Figure 2: An inbound resource adapter for flat files
This method of retrieving data, that is, passing data in the form of a business object, is called non-pass-through or Data Transformation Framework (DTF), and it operates on structured data.
If the application does not know the format of the data files, you can configure the adapter for flat files to run in pass-through mode, operating on unstructured data. In that case, it would not transform an event into a business object.
When you have one record per file, you don't need file splitting. You use file-splitting when the files you want to retrieve are large or they each contain more than one record. You can split files into smaller chunks based on a delimiter or on a fixed-size value, which allows parts of the file to be processed in parallel. Each chunk is considered a separate event and is individually sent to the endpoint component through the exported inbound interface.
Typically, input is stored as a single record per file.
However, when the input file contains more than one
record, you often separate the records in the file with a
delimiter, which can be any text string and is usually a
combination of characters followed by
(platform dependent new line character). The adapter
can both read and write files that contain a delimiter.
Using our examples from Figure 1, we have the string
#### followed by a new line as the delimiter in the XML file (shown in Figure 3), and we have only a new line as the delimiter in the CSV file.
In this case, the adapter splits the input file into two chunks corresponding to two records. It sends the records to the event store one by one, and from there to the endpoint component as separate business objects.
Figure 3: Different types of delimiters
Split by size
The split-by-size feature is similar to splitting by delimiter because you use it to divide a file into smaller chunks and transfer them to the endpoint component one by one. However, use this feature with unstructured data in a pass-though scenario because it is not going to be put into business objects. You specify the split criterion in the adapter as a number of bytes. The adapter reads the file as chunks (events) of that byte size. Each chunk will be the size defined by split criteria, except the last one, which might be smaller.
Data in flat files can come in many different formats, such as the previously discussed XML and CSV formats. Others formats include name and value pairs, tab-separated, and fixed-width formats. Data binding is a method of mapping from the format in the data files to the attributes of a business object.
Using the adapter for flat files default data binding, you can convert files to and from XML format. In other formats, you have to use custom data bindings that define the mapping between the file format and a business object. To implement a custom binding, create a Java class that converts the data for the specific format and enter this class in the Enterprise Service Discovery wizard when you configure the adapter.
For more information about creating a custom data binding, visit Creating custom data bindings in the WebSphere Adapters documentation.
To write or modify files, the application uses the operations defined in the outbound interface, which you create using the Enterprise Service Discovery wizard. The following list shows the operations it creates to work with unstructured data (in pass-through mode):
createFlatFile– stores data to a new file or creates an empty file
appendFlatFile– appends data to an existing file
overwriteFlatFile– overwrites an existing file with a new data
deleteFlatFile– deletes an existing file
retrieveFlatFile– reads content from a file (binary only)
listFlatFile– lists files in a directory
existsFlatFile– checks if a specific file exists
However, if you setup the adapter to work with structured data (in non-pass-through mode or DTF) the Enterprise Service Discovery wizard creates all of the operations and an additional set of seven outbound interface operations that support your specific business objects.
Imagine that you want to create an application that monitors a certain directory in a file system so that you can collect customer record information. When a file is created, the adapter calls the export with the data that is stored in a business object. The export is wired to a business process component that separates the data from the file into individual records that are each placed into their own file in an output directory. This scenario is shown in Figure 4:
Figure 4: The flat file module
When files that contain customer records are in the inbound events directory, the resource adapter retrieves them, creates a customer business object, and calls an export in the module, which initiates a business process. The process generates a new file name based on the number of existing files, and specifies the output directory. Then, the business process writes the customer business object data to a separate XML file in the output directory of the file system.
To create an application that uses the adapter follow these basic steps, which are detailed in the following sections:
- Set up the event store database.
- Import the resource adapter.
- Use the Enterprise Service Discovery wizard to create the inbound flat file service.
- Use the Enterprise Service Discovery wizard to create the outbound flat file service.
- Implement the business logic.
To use the inbound adapter, you first need to set up the event store, which is where inbound data is temporarily stored. You can use any type of database as the event store, but in this example you will use the Cloudscape database that ships with WebSphere Integration Developer. When a component such as a resource adapter on WebSphere Process Server needs database access, it uses a server data source.
To set up the event store:
- Create a database.
- Create a data source on the server that uses that database.
To use the inbound adapter, you have to create the Cloudscape database using the Cview application:
Run the following command:
When the Cview window opens, select
File - New - Database,
and then enter
FlatFilesDBin the Name field.
- Click OK, and then close the Cview application.
Now you need to create a link from WebSphere Process Server to the new database:
- If you haven't started WebSphere Integration Developer yet, do so now and switch to the Business Integration perspective.
- To start the server, go to the Servers view, right-click WebSphere Process Server v6.0, and then select Start.
- When the server has started, right-click the server again and select Run administrative console.
- Log into the administrative console using any user ID.
- In the administrative console, expand Resources on the left pane, and then click the JDBC Providers link.
- Click the Cloudscape JDBC Provider(XA) link and then, on the next page, click the Data sources link.
- Click New to create a new data source.
To link a server data source with the database that you created in the first part of this section:
On the next page (shown in
Figure 5), enter
jdbc/FlatFilesDBin the JNDI name field and then, at the bottom of the page, enter
FlatFilesDBin the Database name field.
Figure 5: The Cloudscape data source
- Click OK, click the save link, and then click Save.
Check the new data source (JNDI name
jdbc/FlatFilesDB) and click Test Connection. You should see a
"Test connection successful"message.
- Log out and close the administrative console.
In this section, you create a module with an export that is called by the inbound adapter (detailed in the following sections):
- Import the resource adapter and create an adapter project.
- Create a module that will contain, at a minimum, the export and the component it will be wired to.
- Use the wizard to discover services and create the export.
As a shortcut, you could use the Enterprise Service Discovery wizard because it lets you create the resource adapter project and the module, but for clarity we will show these three steps individually.
To import the resource adapter into a project:
- In the Business Integration view, right-click and select Import.
- In the Import dialog box that opens, select RAR file, and then click Next.
Next to Connector file, click
Browse and then browse to
- Select the file CWYFF_FlatFile.rar, click Open, and then click Finish. If a dialog box opens asking you whether you want to switch to J2EE perspective, click No, because you are going to continue working in the Business Integration view.
There is now a resource adapter project in your workspace. Note that it is not in the Business Integration view; so don't be worried if can't find it. It will appear in the Enterprise Service Discovery wizard in the next steps.
Next, you will create a new module and then use the Enterprise Service Discovery wizard to create a flat file export in the module.
In the Business Integration view, right-click and
select New - Module
to create a module, and name it
- To open the Enterprise Service Discovery wizard, click File - New - Enterprise Service Discovery.
- Ensure that IBM WebSphere Adapter for Flat files (version 6.0.2) from the CWYFF_FlatFile Connector Project is selected (that is the project that you created in the previous steps), and then click Next. Notice that there is an Import Resource Adapter button. If you click this button, the Import dialog box that you saw in the previous steps opens.
You now need to tell the adapter which business objects you will use to store the inbound data so that the adapter can create the appropriate inbound interface operations. Recall that the adapter creates an interface that has a generic operation for reading unstructured data and an operation specific to the business object for reading structured data. In this example, the data is structured.
Because flat files do not contain metadata that describes the business data structure (unlike other EISs, such as enterprise resource planning or transaction processing systems, which often contain metadata describing their business data), the Enterprise Service Discovery wizard needs a hint to recognize the structure in the files. Therefore, the business objects must exist before the wizard runs. In this case, you use the customer business object that ships with WebSphere Integration Developer as a sample.
Next to Folder Name, click Browse
and then browse to
In the Character Set list, select
UTF-8, and in the Content Type list, select
The wizard should look like
Figure 6: Connection configuration
The following table explains what you just set in step 2:
Folder name indicates where the business objects to be imported by the wizard are located.
When you select text/xml, you indicate which data format the adapter expects when it reads or writes, and the associated DataBinding type, XMLBOSerializerDataBinding, populates the DataBinding type field.
- Click Next.
- On the Find and Discover Enterprise Services page, click Execute Query. You should see the Customer business object under Objects discovered by query.
- Select Customer, and then click Add to import list.
Figure 7 shows the discovered Customer business object. With some EISs, the resource adapter queries the metadata on the backend to discover business objects. In this case the metadata was provided in the form of an XML schema definition file that described the data in the flat files.
Figure 7: The discovered business object
Next, indicate which adapter type (inbound or outbound) you are creating and specify the parameters for this type of adapter and the particular file format of the input files.
- Click Next.
On the Configure Objects page, select
as the service type.
shows setting the service type to inbound. The
operations for the service are grayed out because
they do not apply to an inbound operation. Click
Figure 8: Configure Objects page
On the Generate Artifacts page, ensure SeparateCustomersModule is selected as the module, and then set the values shown in the following table (you can leave the rest of the default values):
DataSource JNDI Name
Event Table Name
Splitting Function Class Name
Event Content Type
- Click Finish.
Figure 9 shows the wizard after filling in the values from the table.
Figure 9: The Generate Artifacts page
The following table gives you information about the values that you can set for the adapter for flat files. For information on other configuration settings, refer to the adapter documentation.
|Poll period||Indicates how often the adapter for flat files checks the inbound event directory. In this example, you used the default value of 2000 milliseconds.|
Indicates how many events (files for non-pass-through operation or business objects for pass-through operations) a adapter for flat files can read from the inbound event directory during one polling period. In this example, you used the default value of 10.
Indicates the path and directory name where the adapter for flat files looks for input files.
The path and directory name where the processed files are archived. Files are not archived by default; so if this field is left empty, the input files are deleted after processing.
DataSource JNDI Name
Refers to the data source for the event store on the server. You set that same name when you created the data store in the first steps. These names must match the name used in the server configuration.
Event Table Name
The name of the table that the adapter for flat files uses for event persistence. The table name is not fixed; you can specify any string here. If the you select the Create Table check box, the event table is automatically created in the database.
The delimiter that the adapter for flat files uses to determine where to split a file. If there is one record per file, the Split Criteria field is empty.
Let's look a bit closer at the split criteria. By
as the split criteria (the semicolon is needed to separate more than one delimiter), we assume that the records in our
input XML file are separated by
and a new line character like in the following example:
… <State>ON</State> </Customer> #### <?xml version="1.0" encoding="UTF-8"?> <Customer> <customerName>Matt</customerName> …
When you enter a delimiter for the split criteria, you
also have to enter a value in the
Splitting Function Class Name
field so that the split criteria points to the following
predefined class (for delimiters):
By specifying a delimiter (or another file-splitting function such as chunk-size), you change the meaning of the poll quantity: from the maximum number of files polled from the events directory each time, to the maximum number of business objects retrieved during each poll. For example, imagine that you set the poll quantity to 10 and there are two files in the events directory. The first file contains nine records and the second file has only two records. When the poll cycle starts, all nine business objects are retrieved from the first file and only the first business object is retrieved from the second file. The remaining object from the second file is retrieved on the next poll cycle.
Figure 10 shows the assembly diagram after the wizard steps are complete. The Appendix to this article contains instructions on splitting by size.
Figure 10: The SeparateCustomersModule after completing the Enterprise Service Discovery wizard
You are finished creating an inbound service that uses the WebSphere Adapter for Flat Files. Let's look at the artifacts that now exist in your workspace.
This export exposes the module to external systems, in this case, the adapter for flat files. This artifact has been added to the assembly diagram.
This interface contains the operations that the Enterprise Service Discovery wizard created.
This operation is called after the adapter for flat files polls the event directory in pass-through mode with unstructured data. It is not used in this example.
This operation is called after the adapter for flat files polls the event directory in non-pass-through mode and process data as a Customer business object.
These business objects and business graphs are created by the Enterprise Service Discovery wizard to contain incoming unstructured data. However, they are not used in this example.
The Customer business object is imported from the sample folder. CustomerWrapper is created by the Enterprise Service Discovery wizard to contain the Customer business object in addition to adapter-specific information. These data types are created only when you provide a business object.
The WebSphere Adapter for Flat Files defines and generates business objects based on data gathered using the Enterprise Service Discovery wizard. For both inbound and outbound processing, it generates the following artifacts:
is a wrapper business object that contains the
business object and file-specific data.
is a business graph that wraps the
business object, as
shows. As we discussed in the first article of this
series a business graph is a
container for a business object that has a verb or
instructions on what to do with the data. However, the
adapter for flat files does not use the verb field of the
business graph. The Enterprise Service Discovery wizard
always creates business graphs, which are sometimes used
as operation parameters for import and export
Figure 11: FlatFileBG business graph
In the previous steps, you configured the adapter to use
structured data (DTF). So the Enterprise Sservice
Discovery wizard generated two additional business
objects, as shown in
Because the folder name in the connection
configuration contained the Customer business object
the business object was imported into the module and
the wizard created
as Figure 12 shows.
Customer BO stores data about a customer, which is the actual data
record that comes from the input file. The business
object has a attribute of type
Customer and multiple other
attributes used to store data that is specific
to the adapter and the operation.
Figure 12: The CustomerWrapperBG business graph
Next, let's create the outbound service:
- Select File - New - Enterprise Service Discovery.
- Ensure that IBM WebSphere Adapter for Flat files (version 6.0.2) from the CWYFF_FlatFile Connector Project is selected (that's the project that you created before you created the inbound service), and then click Next.
Next to Folder Name, click Browse
and browse to
- In the Character Set list, select UTF-8, and in the Content Type list, select text/xml, and then click Next.
- On the Find and Discover Enterprise Services page, click Execute Query, select Customer in the list, click Add to import list, and then click Next.
- On the Configure Objects page, select Outbound as the Service Type, and then click Next.
On the Generate Artifacts page, ensure
is the selected module, and then for the
Output Directory enter
c:\flatfiles\outputdir, and for the Staging Directory enter
- Click Finish.
You have finsihed creating an outbound service that uses the WebSphere Adapter for Flat Files. Figure 13 shows the outbound settings.
Figure 13: The Generate Artifacts page for outbound service
The following table explains the values that you set for the outbound connection properties.
This value indicates the folder to which the output files will be written.
This value indicates the temporary directory where the output files are held before they are copied to the output directory.
Let's take a look at the new artifacts that exist in your workspace:
This import lets you use the flat-file EIS as a service. The import has been added to the assembly diagram.
This interface contains the operations that you use to access the files.
These operations create and manage files in the output directory when you are operating in pass-through mode with unstructured data. These operations are always created, but are not used in this example.
These operations create and manage files in the output directory when you are operating in non-pass-through mode and processing data stored in a Customer business object. These operations are created only when you provide a business object.
These business objects and business graphs contain response data of outbound operations. If the Customer and FlatFile business objects are not created in the previous section, the Enterprise Service Discovery wizard creates these business objects when this wizard creates the outbound service.
The interface operations that the Enterprise Service Discovery wizard generates for an outbound adapter require the following business object and business graph pairs to be generated as well:
ExistsResponse/ExistsResponseBGholds the result of the
existsFlatFileoperation. If a specific file exists in a given directory,
ListResponse/ListResponseBGholds the result of the
listFlatFileoperation. Results are stored as an array of strings. Each string is the name of a file in the directory.
RetrieveResponseWrapper/RetrieveResponseWrapperBGholds the result of the
RetrieveResponseWrappercan contain an array of
FileContentbusiness objects. In general,
retrieveFlatFileoperation returns the content of a given file stored as an array of bytes in the
For more information about business objects and business graphs, see the Business objects that were created in the Inbound section.
When you open the assembly diagram, you see both the
FlatFileInboundInterface) and import
FlatFileOutboundInterface). Now you need to
implement a component to process the data that was
received from the export and sent to the import. In this
section, you learn how to work with the data
received from the flat-file export and how to work with
data in flat files using the flat-file import.
The basic steps to add business logic that make use of both the inbound and outbound adapter for flat files are:
- Create a business process component that is wired between the export and import.
- Implement the logic in the business process.
- Deploy and run the application.
The following steps create a business process component and link it to both the inbound and outbound interfaces, which are the export and import, respectively:
- Under SeparateCustomersModule, double-click AssemblyDiagram to open the assembly editor.
Right-click anywhere on the assembly diagram, select
Add - Process,
and then rename the new component to
- Move your mouse over the edge of the FlatFileInboundInterface component, and then drag the handle to the SeparateCustomers component, which adds a link from the export to the business process component.
When you are asked to add the interface of the
export to the process component, click OK.
FlatFileInboundInterfaceis added to the
In the same way, add a link from the
component to the
import, and click OK
to add the matching reference. A reference with the
FlatFileOutboundInterfaceis added to the
- Save the assembly editor.
The assembly diagram on your screen should now look like the assembly diagram in Figure 14. If you want to learn more about creating business processes, read Business processes in a service-oriented world. Notice that there is an exclamation icon on the SeparateCustomers component to indicate that the component is not implemented. In the next section, you will fix that.
Figure 14: The SeparateCustomersModule implementation
Now, you need to create the business process implementation:
- Double-click the SeparateCustomers component and, when asked to create the implementation, click Yes.
When the Generate Implementation dialog box opens,
so that the
SeparateCustomersModulemodule contains the process implementation.
- When the Process Operation dialog box opens, ensure the emitCustomerWrapper operation is selected, and then click OK.
When the business process editor opens, in the top right
corner of the editor you see an
variable with data type
emitCustomerWrapperInput variable contains data from
flat-file events. You need to add two more variables
that will be used in the process:
- Right-click Variables and select Add Variable.
With the new variable selected, open the
tab in the Properties view and rename it
- On the Details tab, ensure Data Type is selected, click Browse, and then select FlatFileBG for the variable type.
In the same way, create a variable named
ListResponseBGwith the type ListResponseBG.
There are two operations in
the process must contain two corresponding receive
activities. In fact, you might have noticed an error
indicating that the process does not implement the
emitFlatFile operation. In the next steps, you will fix
- Delete the Receive activity and add a ReceiveChoice activity in its place by right-clicking the canvas and selecting Add - ReceiveChoice.
- To avoid a correlation issue that results from having multiple operations defined in the interface, in the Details tab of the properties for this ReceiveChoice activity, select Create a new Process instance if one does not already exist.
- Click the Receive element of the ReceiveChoice activity.
In the Properties view, on the Details tab, click
from the list, select
as the Operation, and then click the Input type
selection button and choose
The properties for the
emitCustomerWrapperreceive activity should now be set as in Figure 15.
Figure 15: The emitCustomerWrapper receive activity properties
- Right-click the ReceiveChoice activity and select Add Receive to add another receive element.
In the Properties view, rename the new receive
emitFlatFile, set the partner to FlatFileInboundInterface, set the operation to emitFlatFile, and then set the input variable type to EmitFlatFileInput. The properties for the emitFlatFile receive activity should be set as in Figure 16.
Figure 16: The emitFlatFile receive activity properties
In this example, you do not use the
emitFlatFileoperation (for unstructured data); so add an
Empty Actionunder the
EmitCustomerWrapperInput contains the data
received from the
emitCustomerWrapper operation. Because you will write the content of variable
EmitCustomerWrapperInput to the output file, you need a snippet to reset the directory path (set as the inbound event directory during the inbound processing) to the output directory. When
the directory path is an empty string, the
outbound adapter for flat files uses the default output
directory configured by the Enterprise
Service Discovery wizard, which you set to
c:\flatfiles\outputdir when you created the outbound
In the next steps, you will add a snippet, as shown in
that sets the
directoryPath field of
EmitCustomerWrapperInput variable to an empty string
Under emitCustomerWrapper, add a snippet
activity and rename it to
In Properties view, on the Details
tab, assign an empty string to variable
EmitCustomerWrapperInput.CustomerWrapper.directoryPathby selecting Add - Expression and typing two double quotation marks in the expression node. Alternatively, you can drag EmitCustomerWrapperInput onto the canvas and use the menu to select the nested business objects and attributes.
Figure 17: The ResetDirectoryPath visual snippet
Now you need an activity to check how many files are in the output directory so that you can add the appropriate sequence number in the output file name:
Under the ResetDirectoryPath
snippet, add an Invoke activity and rename it to
Set the details to those shown in
Figure 18: The InvokeListResponse invoke activity properties
The content of
ListResponseBG business graph in the
InvokeListResponse properties is the list of files in
c:\flatfiles\outputdir directory. You will use this
directory because the
directoryPath field of the
EmitCustomerWrapperInput is empty.
In the next steps, you create another snippet activity to create the file name for the output file. The file name will have the format <customerName><Sequence>.xml. (If you are familiar with creating snippets, you might find it easier to create the snippet using the information in Figure 19.)
Under InvokeListResponse, add a snippet activity and
rename it to
Add a node for the
Add a list size node by selecting
Add - Standard - list size.
The list size node indicates the number of file
names stored in
ListResponseBG.ListResponse.listOfFileNamesvariable node to the
to textnode by selecting Add - Standard - Utility - to text. The
to textnode creates a string from the size integer that will be the sequence number in the file name.
- Wire the list size node to the totext node.
Add a node for the
append textnode by selecting Add - Standard - Text - append text, wire the node on the
EmitCustomerWrapperInput.CustomerWrapper.content.customerNamevariable to the top input of the append text node, and then wire the to text node to the bottom input of the append text node.
Create a second
append textnode to add the string
.xmlto the output of the first
append textnode, and assign the output of the second
append textnode, which is the entire file name string, to the
The resulting snippet should look like Figure 19:
Figure 19: The ResetFileName visual snippet
The outbound operation
createCustomer creates a new file with the file name that you set in thefileName
field of the
EmitCustomerWrapperInput variable, and writes the file in the output directory that you set earlier using the empty string.The
outbound operation is created in the output directory
that you set earlier using the empty string, and writes
the content of a
Customer business object to a file
using the adapter for flat files. In the few remaining steps, you create an activity to call that
In the process editor, add an Invoke
activity under ResetFileName
and rename it to
Set the details to the information shown in Figure 20:
Figure 20: The InvokeCreateCustomer invoke activity
- Save the business process editor.
The final implementation of the component
SeparateCustomers on your screen should look like Figure 21:
Figure 21: The SeparateCustomers business process
You have finished implementing the application. Before deploying it to the server and testing it, you just need to create the directories that you specified in the Enterprise Service Discovery wizard:
c:\flatfilesfolder, and create four subfolders in it:
Copy the input files from the
input.zipfile provided in the Downloads section into the
You are now ready to deploy and test the application!
- Go to the Servers view, right-click WebSphere Process Server, and select Start.
- Right-click WebSphere Process Server again and select Add and remove projects.
- Select SeparateCustomersModuleApp, and then click Add.
- Click Finish and wait for the server to start and for the module to deploy.
The inbound polling automatically starts after the
application deploys. You should see the message
has started." in the console view. Check the contents of
c:\flatfiles\inboundevents directory; the input
files in this folder have been deleted.
For every event that the inbound portion of the
adapter for flat files polled and processed, you see a
event has been delivered" message in the Console view.
c:\flatfiles\outputdir directory. You see a
list of XML files with a filename matching
The content of each file is a single customer
The IBM WebSphere Adapter for Flat Files enables your business components to interact with plain text files that were created or consumed by enterprise information. You have learned how to set up the resource adapter for flat files and use it in an application.
If you want to split a file by size, do one of the following actions:
- Enter an integer value for the split criteria representing the maximum size of the event (in bytes)
Set the Splitting Function Class Name to
For more details, see the information about adapters in the resources section.
If you cannot access the
you can create your own using a text editor. The input file
should follow this format:
<?xml version="1.0" encoding="UTF-8"?> <customer:Customer xmlns:customer= "http://www.ibm.com/xmlns/prod/websphere/j2ca/flatfile/customer"> <customerName>John</customerName> <Address>83 Queens Street</Address> <City>Ottawa</City> <State>ON</State> </customer:Customer> #### <?xml version="1.0" encoding="UTF-8"?> <customer:Customer xmlns:customer= "http://www.ibm.com/xmlns/prod/websphere/j2ca/flatfile/customer"> <customerName>Matt</customerName> <Address>1435 Carling Ave.</Address> <City>Ottawa</City> <State>ON</State> </customer:Customer> ####
Note that a RETURN has to be included at the end of the
input file, to ensure the delimiter
included correctly for the last Customer record.
|Sample input files||inputfiles.zip||1 KB||FTP|HTTP|
|Completed SeparateCustomers module||completedmodule.zip||1340 KB||FTP|HTTP|
Overview of all WebSphere adapters
Introduction to creating business processes with WebSphere Integration Developer
Enterprise Metadata Discovery
WebSphere Adapter Development Redbook
J2EE Connector Architecture 1.5 specification
A guided tour of WebSphere Integration Developer
WebSphere Integration Developer product information
developerWorks: WebSphere Process Server and WebSphere Integration Developer resources
developerWorks: WebSphere Business Integration zone
developerWorks: WebSphere development tools zone
Meet the experts: WebSphere Integration Developer
Get products and technologies
Mandy Habinski is a software tester at the IBM Ottawa Lab on the WebSphere Integration Developer team. Her responsibilities include creating small scale applications for component and cross-component test, revising and executing Functional Verification Tests.
Tanya Ruppell is a Team Lead at IBM Canada Ltd for the WebSphere Integration Developer Test Team. She and her team are responsible for automated GUI testing and cross-component testing of WebSphere Integration Developer and Message Broker Toolkit.
Artur Ruszczynski is a software developer at the IBM Ottawa Lab on the WebSphere Integration Developer Testing team. His responsibilities include developing and executing automated cross-component tests.
Richard Gregory is a software developer at the IBM Toronto Lab on the WebSphere Integration Developer team. His responsibilities include working on the evolution and delivery of test tools for WebSphere Integration Developer.
Greg Adams was the lead architect for the user interface in the award-winning Eclipse platform, and more recently, has been the lead architect and development lead in the core WebSphere Business Integration Tools, including WebSphere Studio Application Developer Integration Edition and WebSphere Integration Developer. Greg led the delivery of IBM's first complete services oriented architecture (SOA) tools stack and the first BPEL4WS standards supporting Business Process Editor; both critical deliverables in support of IBM's On Demand strategy.