Integrate data with Cloudant and CouchDB NoSQL database using IBM InfoSphere Information Server

Use DataStage's Hierarchical Data stage

In this article, learn how to use the Cloudant database and CouchDB with the IBM® InfoSphere® DataStage® V11.3 Hierarchical stage (previously called XMLConnector). Detailed examples show how to invoke the Cloudant API, using the REST service of the Hierarchical Data stage, to access and change data on the Cloudant DB with support of HTTP basic authentication. You can modify the example to perform the same integration operations on a CouchDB database. The examples also use other steps of the Hierarchical stage to retrieve documents and parse or compose the retrieved documents into a relational structure.

Share:

Jeff J. Li (liji@us.ibm.com), Software Architect, IBM

Jeff LiJeff Li is a software architect in the Software Group in Boca Raton, FL. He has worked with enterprise applications and data integration for 15 years. Currently, he is leading the development of the complex data integration solution for IBM InfoSphere Information Server.



Shweta R Sugurmath (ssugurma@in.ibm.com), QA Engineer, IBM

Shweta R. SugurmathShweta R. Sugurmath is a quality assurance engineer for the Hierarchical DataStage of the Information Server. She has been with Hierarchical Stage for more than two years.



10 July 2014

Also available in Chinese

Introduction

IBM Cloudant is a hosted, distributed database as a service (DBaaS) based on the CouchDB-based NoSQL database. Cloudant is a schema-less JSON document store that offers an enterprise-class DBaaS solution to greatly simplify and accelerate your development of mobile and web applications. Cloudant and CouchDB expose similar HTTP-based Representational State Transfer (REST) services for external applications to access their database documents and related services.

IBM InfoSphere DataStage is a comprehensive information integration platform. It profiles, cleanses, and transforms data from heterogeneous data sources to deliver consistent and accurate business data. It is an ideal solution to integrate and synchronize enterprise data with cloud database services and NoSQL databases.

Download and try IBM InfoSphere products.

In this article, learn how to use IBM InfoSphere DataStage to integrate the Cloudant database services and CouchDB NoSQL database. Two business integration scenarios provide examples that can help customers solve their integration issues.

You can download the sample jobs used in this article.


Prerequisites

To follow along with the examples in this article, you need:

  • Cloudant, which is a hosted distributed DBaaS based on the Apache CouchDB. It enhances the CouchDB with scaling, fault tolerance, Lucene-based indexing and search, geo-spatial indexing, and global data distribution. It offers 24x7 reliability.
  • CouchDB, which is a schema free, document-oriented database management system to enable web or mobile applications to save JSON documents and their attachments. Users can create MapReduce views using JavaScript to aggregate and report on the documents in a database. By using multiple version concurrency control and incremental replication, CouchDB supports concurrent read and write, high availability, fault tolerance, and data eventual consistency.
  • IBM InfoSphere DataStage, which integrates data from various sources using a high-performance parallel framework and supports metadata management and enterprise connectivity. The Hierarchical Data stage is a component within the DataStage Picasso release V11.3 responsible for transforming hierarchical data and invoking REST web services. It includes the following step types, as shown in Figure 1:
    • Transformation steps for performing transformation operations on hierarchical data, such as joining two hierarchical data structures based on key fields using the HJoin step.
    • XML Parser and Composer for parsing or composing XML data based on an imported XML schema.
    • JSON Parser and Composer for parsing or composing JSON data based on a schema generated from JSON sample data.
    • REST step for consuming REST web services. The sample jobs in this article use the REST step to invoke the Cloudant database services.
    Figure 1. Steps of Hierarchical Data stage
    Steps of Hierarchical DataStage

Cloudant and CouchDB HTTP-based REST API

Cloudant and CouchDB embrace web technologies; they expose REST web services as the integration point for other external applications to perform database operations and access documents stored in the databases. Databases, documents, and attachments are all represented as REST resources. A REST resource is identified by an HTTP URI. To manipulate database resources, the client applications communicate via HTTP protocol and exchange representations of these resources. In Cloudant and CouchDB, the representations are specified in JSON data format. HTTP methods are used to create, update, read, or delete resources.

The Cloudant REST API is very similar to the CouchDB REST API. One major difference is that Cloudant requires user credentials for most requests. There are two separate authentication mechanisms:

  • The HTTP basic authentication to pass the user name and password.
  • The HTTP cookie AuthSession. An application can post a request for the resource _session to get the cookie value and then use that cookie value for other requests.

Scenario 1. Compose and load JSON documents into Cloudant

In this scenario, a sample DataStage job, shown in Figure 2, walks you through the steps to compose and load JSON documents into Cloudant. The job extracts the data from the sequential files, composes JSON documents, and loads the JSON documents to Cloudant using the Hierarchical Data stage. The processing results are checked to make sure that the documents are loaded into Cloudant.

Figure 2. Example DataStage job
Compose and Load JSON Documents to Cloudant

Figure 3 shows the parameters set for the job. They're used at run time to specify the Input Directory, Output Directory, Cloudant UserName, Cloudant Password, and Cloudant Database Name.

Figure 3. Job parameters
Job Parameters

Figure 4 shows the table definitions in the Contacts and PhoneNumbers Sequential File stage.

Figure 4. ColumnNames created in the Sequential File
ColumnNames created in the Sequential Files

The contents of the Sequential File are in:

Contacts.txt
            
1,"Smith","NY","21 2nd Street","10021","New
York","IBM","John","25","C:\srs\image1.jpg" 2,"Holmes","FL","31 2nd
Street","33076","Boca Ration","IBM","David","48","C:\srs\image2.jpg"
Phonenumbers.txt
            
1,"212 555-1234","home" 1,"646 555-4567","fax" 2,"561-862-0000","cell"

Figure 5 shows the Assembly Editor of the Hierarchical Data stage.

Figure 5. Assembly Editor
Assembly Editor Design

Double-click the Hierarchical Data stage to open the stage properties, then click Edit Assembly to open the Assembly Editor. From the palette, double-click the HJoin, JSONComposer, REST and JSONParser steps to add them to the assembly outline.

Design the assembly

To compose JSON documents and then load the documents to Cloudant:

  1. The assembly uses the default Input step, which shows the columns created in the Sequential File stages (as in Figure 4).
  2. The HJoin step, shown in Figure 6, creates a master-detail structure from contact information and phone numbers. Each contact may contain one or more phone numbers.
    Figure 6. HJoin step
    HJoin step

    The Hjoin step contains two input lists: Contacts and PhoneNumbers. While configuring the HJoin step, select Contacts list as the Parent List and PhoneNumbers as the Child List. Use the key id to join the ParentList to the PhoneNumbers List.

    As shown in Figure 7, the HJoin step output shows the addition of the PhoneNumbers list as a child of the Contacts list. The output also contains a new node name of HJoin:orphans, which contains the phone numbers that do not have matching contacts.

    Figure 7. HJoin output
    HJoin Output
  3. Configure the ComposeJson step, as in Figure 8, to compose JSON documents based on the master-detail structure created by the previous H-Join step.
    Figure 8. JSON Target tab of ComposeJson step
    JSON Target tab of ComposeJson step

    Select Pass as string to pass the composed JSON string to the next step for further processing.

    The JSON schema to be used under the Document Root tab of the ComposeJson step is:

    { "firstName": "John", "lastName": "Smith", "age": "25", "address": {
     "streetAddress": "21 2nd Street", "city": "New York", "state": "NY",
    "postalCode": "10021" }, "phoneNumbers": [ { "type": "home", "number": "212
    555-1234" }, { "type": "fax", "number": "646 555-4567" } ], "companyName": "IBM"}

    The schema is created based on the structure created by the previous HJoin step. The JSON schema is imported in the Schema Library Manager under the library JSON, as shown in Figure 9 and Figure 10.

    Figure 9. Create library in Schema Library Manager
    Create library in Schema Library Manager
    Figure 10. Importing JSON Schema in library
    Importing JSON Schema in library

    From the Document Root tab, as shown in Figure 11, browse and select the schema imported under the library JSON.

    Figure 11. Document Root tab of ComposeJson step
    Document Root tab of ComposeJson step

    Figure 12 shows the Validation tab of the ComposeJson step, where Strict Validation is selected. By default, the JSON Composer uses strict validation. The job fails if a violation occurs.

    Figure 12. Validation tab of ComposeJson step
    Validation tab of ComposeJson step

    From the Mappings tab, as in Figure 13, you need to create mappings for the document_collection item. Mapping this item determines whether single or multiple JSON documents are created. The Contacts List item is mapped to the document_collection in order to produce one JSON document for each contact.

    Figure 13. Mappings tab of ComposeJson step
    Mappings tab of ComposeJson step

    As shown in Figure 14, specify UTF-8 as the Encoding type and select Format style.

    Figure 14. Format tab of ComposeJson step
    Format tab of ComposeJson step

    The result-string holds the composed JSON document, as in Figure 15.

    Figure 15. ComposeJson Output
    ComposeJson Output
  4. The LoadDocToCloudant REST step is created to load JSON documents (composed by the ComposeJson step) to the Cloudant database. As shown in Figure 16, select the HTTP method PUT to store the JSON documents to the Cloudant database as resources. A reusable connection is created so that the session is reused by other REST steps that use reusable connections of the same server in the same assembly.
    Figure 16. General tab of LoadDocToCloudant step
    General tab of LoadDocToCloudant step

    The server and authentication details for the reusable connection are specified in Figure 17 and Figure 18. The URL Suffix is specified to complete the URL address for resources. In our example, the resource URI is identified as the cloudant databaseName followed with docID. The docID is a local parameter whose value will be mapped to the input data field id in the Mappings tab.

    Under the General tab, click Insert Parameter... and select the parameters for the Server host name, as in Figure 17.

    Figure 17. Setting the reusable connection, General tab
    Setting the reusable Connection : 1.General tab

    Under the Authentication tab, click Insert Parameter... and select the parameters for the Cloudant User name and Password, as in Figure 18. The Insert Parameter window contains the list of parameters that are defined as job parameters in Figure 3.

    Figure 18. Setting the reusable connection, Authentication tab
    Setting the reusable Connection : 2. Authentication tab

    Figure 19 shows the addition of local parameters to the URL. In the Local parameter field, enter docID and click OK to add the parameter to the URL.

    Figure 19. Adding local parameter
    Adding local Parameter

    The Security details of the REST web service, which are copied from the reusable connection, are shown in Figure 20.

    Figure 20. Security tab of LoadDocToCloudant step
    Security tab of LoadDocToCloudant step

    As shown in Figure 21, the Request tab specifies the information contained in the REST service request, as follows:

    • Select Load the Outgoing body from:.
    • Select A text node named body on the Mappings page. This option creates a text node named "body" in the target schema on the Mappings tab. The node “body” needs to be mapped to an input text node that contains the REST request body.
    • From the Content type list, select application/ and json. This option indicates that the REST request body is a JSON document.
    • From the Encoding type list, select UTF-8, which indicates the character encoding of the REST request body.
    • Under Custom headers, specify Accept:application/json. This tells the REST service server that our application is expecting a REST response in JSON data format.
    Figure 21. Request tab of LoadDocToCloudant step
    Request tab of LoadDocToCloudant step

    As shown in Figure 22, the Response page specifies the information related to the REST service response, as follows:

    • Select Pass the received body to:.
    • Select A text node named body in the Output Schema. This option creates a text node “body” in the output schema for this step to capture the REST response body.
    • From the Content type list, select application/ and json. This specifies the expected content type of the REST response body.
    Figure 22. Response tab of LoadDocToCloudant step
    Response tab of LoadDocToCloudant step

    The Mappings tab, in Figure 23, shows where the connection and request elements are mapped to the input data fields. The local parameter docID is mapped to the id of the Contacts list, and the body node is mapped to the JSON string created by the ComposeJson step.

    Figure 23. Mappings tab of LoadDocToCloudant step
    Mappings tab of LoadDocToCloudant step

    The output schema of the LoadDocToCloudant step is shown in Figure 24.

    Figure 24. LoadDocToCloudant output
    LoadDocToCloudant Output

    Two group nodes are created under the PUTResponse schema. The callStatus group node holds details about the status of invoking the REST service:

    • success contains a boolean value True/False. True indicates a successful run and False indicates a failure.
    • errorMessage contains the error message if the REST call fails.
    • FaultHTTPStatusCode contains the HTTP status code if the REST call fails.
    • FaultHTTPBody contains the text HTTP body if the REST call fails.

    The statusLine group node contains the following details:

    • httpVersion returns the HTTP version in the REST response.
    • StatusCode returns the HTTP status code in the REST response.
    • ReasonPhrase returns the HTTP reason phrase in the REST response.
    • The body element is created to return the HTTP body of a REST response.

    Figure 25 shows the JSON data loaded into Cloudant.

    Figure 25. JSON Document in Cloudant
    JSON Document in Cloudant

    In Figure 25, you can see _id and _rev in the JSON document. The _id field is a key to identify a JSON document in the Cloudant database. Cloudant uses the multiple version concurrency control for resolving conflicts that occur during parallel read and write to a JSON document. The _rev field contains the revision number of a specified document.

  5. The next task is to configure the ParseLoadResult JSON parsing step. After the request is sent to the server to load the document, the server sends the response. To read the required elements from the response body, a parser is used. It is responsible for parsing the response received from Cloudant about the operation of loading a JSON document in the LoadDocToCloudant step.

    Figure 26 shows the JSON Source tab of the ParseLoadResult step. String set is selected. From the String set options, select the body from the response of the previous LoadDocToCloudant step.

    Figure 26. JSON Source tab of ParseLoadResult step
    JSON Source tab of ParseLoadResult step

    In the Document Root section, shown in Figure 27, use the following schema:

    input1.json

    {"ok":true, "id":"1", "rev":"8-7163f5dc218b638d89a4ae9be471562b"}

    The schema is first imported in the Schema Library manager and then used.
    Figure 27. Document Root tab of ParseLoadResult step
    Document Root tab of ParseLoadResult step

    Figure 28 shows ParseLoadResult step Validation, where Strict Validation is selected as the default.

    Figure 28. Validation tab of ParseLoadResult step
    Validation tab of ParseLoadResult step

    The output of the ParseLoadResult is shown in Figure 29.

    Figure 29. Output of ParseLoadResult step
    Output of of ParseLoadResult step

    The images to be loaded to the JSON documents of Cloudant are shown in Figure 30.

    Figure 30. Images
    Images
  6. This step shows how to configure the LoadImage REST step. It is created to load the images as attachments to the JSON documents loaded into Cloudant in the LoadDocToCloudant step.
    As shown in Figure 31:
    • Select PUT for the HTTP method to upload the attachments to Cloudant. It uses the reusable connection created in the earlier REST LoadDocToCloudant step.
    • The URL suffix contains the Cloudant database name, local parameter docID, and the image name.
    Figure 31. General tab of LoadImage REST step
    General tab of LoadImage REST step

    The Security tab, as shown in Figure 32, contains the security details as mentioned in the reusable connection configuration.

    Figure 32. Security tab of LoadImage REST step
    Security tab of LoadImage REST step

    Figure 33 shows the Request tab configuration as follows:

    • Select Load the Outgoing body From:.
    • Select A file whose path is set in mappings as bodyFilePath. A node bodyFilePath node is created in the target schema in the Mappings tab. The node is mapped to the input data field ProfilePhoto, which contains the file paths to the images to be loaded to Cloudant.
    • Select Content type image/ and jpeg to indicate the attachments are jpeg images.
    • Under Custom headers, Accept:application/json and If-Match are created. Cloudant uses the multiple version concurrency control to control the concurrent read and write to a document. The revision number provided in If-Match is used by Cloudant for validation against the current version of the document.
    Figure 33. Request tab of LoadImage REST step
    Request tab of LoadImage REST step

    Figure 34 shows the Response tab configuration as follows:

    • Select Pass the received body to:.
    • Select A text node named body in the Output schema.
    • Select application/ and json for Content type.
    The response tab is configured to receive the REST response body in the application/json format, as Cloudant sends the response in json format.
    Figure 34. Response tab of LoadImage REST step
    Response tab of LoadImage REST step

    As shown in Figure 35, the Target RESTRequests is mapped to the InputLinks Contacts and the local parameter docID is mapped to the element id of the Contacts list. Under the Target headers, If-Match is mapped to the element rev (content of the earlier Parser step), and the BodyFilePath is mapped to the element profilePhoto of the Contacts list that contains the file path to the images.

    Figure 35. Mappings tab of LoadImage REST step
    Mappings tab of LoadImage REST step
  7. Now you can configure the JSON parsing step ParseLoadImage. It is responsible for parsing the response received from Cloudant for loading attachments in the LoadImage step.

    As shown in Figure 36:

    • Select String set:.
    • Select the body from the response of the previous LoadImage step from the list under String set.
    Figure 36. JSON Source tab of ParseLoadImage step
    JSON Source tab of ParseLoadImage step

    The configurations of the Document Root and Validation tabs are similar to the LoadParseResult step.

  8. The next task is to configure the Output step. Figure 37 shows the Mappings tab configuration of the Output step. The Target list LoadResult is mapped to the Input list Contacts.
    Figure 37. Mappings tab
    Mappings Tab

    The Sequential File LoadResult contains the Output, as shown in Figure 38.

    Figure 38. LoadResult Output
    LoadResult Output

    Figure 39 shows the JSON document with id 1 and the attachments loaded to it in Cloudant.

    Figure 39. JSON document with attachment in Cloudant DB
    JSON Document with attachment in the Cloudant db

Scenario 2. Extract and Parse a JSON document from Cloudant

The following scenario contains a sample job to illustrate the steps to extract the JSON documents and attachments from the Cloudant database and then parse the retrieved documents to create relational structures.

The job uses flat files as inputs and outputs, as shown in Figure 40. The two stage instances in the middle are the Hierarchical Data stage. The ExtractParseDoc instance retrieves and parses the JSON document from Cloudant. The ExtractImage instance gets the images from Cloudant and saves them to the local file system.

Figure 40. Job design to extract data loaded from Cloudant
Job Design to Extract the loaded data from Cloudant

As shown in Figure 41, the DocId sequential file contains the input data, which lists the document Ids.

Figure 41. Show the input data
show the Input Data

Figure 42 shows the Assembly design of ExtractParseDoc, the first Hierarchical stage.

Figure 42. Assembly Editor design of ExtractParseDoc
Assembly Editor design of ExtractParseDoc
  1. The Input Step holds the column definitions, as shown in Figure 41.
  2. GetDocument is the REST step configured to fetch the documents from Cloudant.

    As shown in Figure 43, from the General tab select GET as the HTTP method to fetch the documents.

    Figure 43. General tab of GetDocument REST step
    General tab of GetDocument REST STep

    Figure 44 shows the Security tab details of the REST Web Service.

    Figure 44. Security tab of GetDocument REST step
    Security tab of GetDocument REST step

    The Request tab information is not configured because the GET HTTP method is selected.

    In the Response tab, as shown in figure 45, select:

    • Pass the received body to:
    • A text node named body in the Output Schema
    • application/ and json for the Content type
    Figure 45. Response tab of GetDocument REST step
    Response tab of GetDocument REST STep

    In the Mappings tab, map the RESTRequest list to the input link DocID and map the local parameter docId to the input column docId, as shown in Figure 46.

    Figure 46. Mappings tab of GetDocument REST step
    Mappings tab of GetDocument REST step

    Figure 47 shows the output of the GetDocument step.

    Figure 47. Output of GetDocument step
    Output of GetDocument step
  3. The ParseDocResult JSON parsing step parses the documents retrieved from the previous GetDocument step.
    From the JSON Source tab, as shown in Figure 48, select:
    • String set
    • The response body of the previous REST step from the list under String set
    Figure 48. JSON Source tab of ParseDocResult step
    JSON Source tab of ParseDocResult step

    The JSON document loaded into the database in the job in Scenario 1 can be used as the JSON schema under Document Root.

    The following input2.json schema was imported to the Schema Library Manager and used.

    { "_id": "1", "_rev": "8-7163f5dc218b638d89a4ae9be471562b", "firstName": "John",
                        "lastName": "Smith", "age": "25", "address": { "streetAddress": "21 2nd Street",
                        "city": "New York", "state": "NY", "postalCode": "10021" }, "phoneNumbers": [ {
                        "type": "home", "number": "212 555-1234" }, { "type": "fax", "number": "646
                        555-4567" } ], "companyName": "IBM", "_attachments": { "image1.jpg": {
                        "content_type": "image/jpeg; charset=UTF-8", "revpos": 8, "digest":
                        "md5-TfqSzzNzVLoeDi1gqlDTxg==", "length": 4521, "stub": true } } }

    As shown in Figure 49, browse and select the imported schema.

    Figure 49. Document Root tab of ParseDocResult step
    Document Root tab of ParseDocResult step

    Figure 50 shows the Output for the ParseDocResult.

    Figure 50. Output of ParseDocResult
    Output of ParseDocResult
  4. The next task is to configure the Output step. In the Mappings tab, the target lists PhoneNumber, ImageInput, Json, and Contact are mapped to the parsed output under Input Lists, as in Figure 51.
    Figure 51. Mappings tab of Output step
    Mappings tab of Output step

    The Sequential File Extractresult contains the retrieved elements, as in Figure 52.

    Figure 52. ExtractResult contents
    ExtractResult Contents

    The Sequential File ContactResult contains the retrieved contact details, as in Figure 53.

    Figure 53. ContactResult contents
    ContactResult Contents

    The Sequential File PhoneNumber contains the retrieved Phone numbers, as in Figure 54.

    Figure 54. PhoneNumber contents
    PhoneNumber Contents

Figure 55 shows the assembly design of ExtractImage, the second Hierarchical stage.

Figure 55. Assembly Editor design of ExtractImage
Assembly Editor design of ExtractImage

The Input Step contains the table definitions, as shown in Figure 56.

Figure 56. InputData
InputData

The GetImage REST step is configured as in Figure 57. Select GET as the HTTP method to fetch the images. The URL suffix is identified with the Cloudant database name followed with docID and image.

Figure 57. General tab of GetImage step
General tab of GetImage step

Security tab: as shown in Figure 58, the security details of the REST step are copied from the reusable connection configuration.

Figure 58. Security tab of GetImage step
Security tab of GetImage step

Request tab: There is no need to configure the request step as the HTTP method selected is GET.

The Response tab configuration follows, as shown in Figure 59:

  • Select Pass the received body to:.
  • Select A file whose path is set below.
  • Specify the Output directory, Filename prefix, and File extension so that the retrieved images are saved to a file system.
  • Select image/ and jpeg for Content type.
Figure 59. Response tab of GetImage step
Response tab of GetImage step

Under the Mappings tab, as shown in Figure 60, map the Input list ImageInput to the RESTRequests list so that one REST service call is made for each image. The docID of the input list ImageInput is mapped to the local parameter docId, which is used in defining the URL of the rest service calls.

Figure 60. Mappings tab of GetImage step
Mappings tab of GetImage step

The Output for the GetImage step is shown in Figure 61.

Figure 61. Output of GetImage
Output of GetImage

To configure the Output step, the target list Image is mapped to the input List ImageInput, under Mappings tab as shown in Figure 62.

Figure 62. Mappings tab of Output step
Mappings tab of Output step

ImageDoc Sequential File contains the extracted image file, as shown in Figure 63.

Figure 63. Image contents
Image Contents

Conclusion

This article provided detailed steps for loading JSON documents and attachments to Cloudant. You learned about the job design to retrieve JSON documents and attachments from Cloudant. You can modify the sample jobs to perform the same integration operations on a CouchDB database. We also covered the main features of the new REST step in InfoSphere DataStage V11.3, including reusable connection, parameterized URLs, security configuration, and request and response configurations. The JSON parser step was used in examples to parse JSON documents.


Acknowledgements

We would like to thank Deepa Y Ramamurthy and Poonam Sharma for their feedback and reviews on this article.


Downloads

DescriptionNameSize
Sample Job1 for this articleComposeLoadToCloudant.zip52.7KB
Sample job 2 for this article 1ExtractParseFromCloudant.zip76.9KB

Note

  1. The sample jobs include the inputfiles, dsx, schema files, and output files.

Resources

Learn

Get products and technologies

  • Evaluate IBM products in the way that suits you best: Download a product trial, try a product online, or use a product in a cloud environment.

Discuss

  • Get involved in the My developerWorks community. Connect with other developerWorks users while exploring the developer-driven blogs, forums, groups, and wikis.

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Information management on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Information Management
ArticleID=977162
ArticleTitle=Integrate data with Cloudant and CouchDB NoSQL database using IBM InfoSphere Information Server
publish-date=07102014