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.
What is a flat file?
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)
What is the WebSphere Adapter for Flat Files?
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.
What are inbound and outbound processing?
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
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.
Custom data binding
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.
Using the adapter for flat files in an application
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.
Building the application
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.
Creating the event store
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.
Creating the inbound service
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.
Import the resource adapter
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.
Discover the flat file service
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 text/xml. The wizard should
look like Figure 6.
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 Inbound as the
service type. Figure 8 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 Next.
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 selecting
####;\n 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
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.
Business objects that were created
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:
FlatFile is a wrapper business object that contains the
UnstructuredContent business object and file-specific data.
FlatFileBG is a business graph that wraps the
FlatFile business object, as Figure 11 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 interfaces.
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 Figure 12. Because the folder
name in the connection configuration contained the Customer business
object (see Figure 7), the business object
was imported into the module and the wizard created
CustomerWrapperBG as Figure
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
Customer and multiple other attributes used to store
data that is specific to the adapter and the operation.
Figure 12: The CustomerWrapperBG business graph
Creating the outbound service
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
SeparateCustomersModule 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.
Business objects that were created
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.
Implementing the business logic
When you open the assembly diagram, you see both the export (called
FlatFileInboundInterface) and import (called
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.
Create the business process component
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
SeparateCustomers component to the
FlatFileOutboundInterface import, and click
OK to add the matching reference. A reference
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
Implement the business process
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, click
OK 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
emitCustomerWrapperInput variable with data
emitCustomerWrapperInput variable contains data from
flat-file events. You need to add two more variables that will be used in
- Right-click Variables and select Add Variable.
- With the new variable selected, open the Description
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
FlatFileInboundInterface; so the
process must contain two corresponding receive activities. In fact, you
might have noticed an error indicating that the process does not implement
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
FlatFileInboundInterface from the list, select
emitCustomerWrapper as the
Operation, and then click the Input type
EmitCustomerWrapperInput. 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 element to
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
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 service.
In the next steps, you will add a snippet, as shown in Figure 17, that
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.
Figure 18: The InvokeListResponse invoke activity properties
The content of
ListResponseBG business graph in the
InvokeListResponse properties is the list of files in the
c:\flatfiles\outputdir directory. You will use this directory
directoryPath field of the variable
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
- Wire the
ListResponseBG.ListResponse.listOfFileNamesvariable node to the
- Add a
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
- Add an
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
business object to a file using the adapter for flat files. In the few
remaining steps, you create an activity to call that operation:
- 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
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:
- Create a
c:\flatfilesfolder, and create four subfolders in it:
- Copy the input files from the
input.zipfile provided in the Downloads section into the
Testing the application
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 the
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
c:\flatfiles\outputdir directory. You see a list of
XML files with a filename matching
content of each file is a single customer data record.
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.
Split by size
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.
Sample input file
If you cannot access the
input.zip file, 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
####;\n is included correctly for the
last Customer record.
|Sample input files||inputfiles.zip ( HTTP | FTP )||1 KB|
|Completed SeparateCustomers module||completedmodule.zip ( HTTP | FTP )||1340 KB|
- 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
- Adapter documentation
- 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