Discussions

News: Otemba OS Project Provides JCA 1.0 Adaptor for MS Excel

  1. Otemba is a new open source product that provides a JCA 1.0 compliant resource adapter for MS Excel, and eventually other MS Office products.

    Check out http://sourceforge.net/projects/otemba.


    More info
    --------------
    Microsoft Excel? dominates on front office trading systems whilst JBoss? leads in the open source application server for both internets and intranets.
     
    Otemba is a new open source project that aims to combine both worlds by transparently wrapping Excel in a JCA 1.0 compliant resource adapter. JBoss's support of JCA 1.0 together with it's highly transparent microkernel architecture makes it the ideal platform for implementing the Excel adapter. The result is that Excel acquires the connection-, transaction- and security management of JBoss.
     
    If successful, Otemba plans to produce adapters for all Microsoft Office? products.
    [http://sourceforge.net/projects/otemba]
  2. What is the pros and cons of using this product vs. the Apache POI? Is this Adaptor transaction-aware?
  3. Is there a JCA Adapter for simply accessing File Systems?

    Thanks

    Mike
  4. "Is there a JCA Adapter for simply accessing File Systems? "

    see:
    http://dev2dev.bea.com/code/codedetail.jsp?productType=weblogic+integration&codeType=code+sample&highlight=samples

    There are a couple of example file JCA adapters for use with WebLogic Integration.

    This adapter allows you to define an application view to accomplish the following tasks:

    1. Take an XML message, transform it to a non-XML format using WLXT, and write the transformed data to a local or remote file system.

    2. Take an XML message and write it to a local or remote file system, i.e. no WLXT transformation.

    3. Read a non-XML file from a local directory or from a remote FTP server, transform it to XML using WLXT, and post the XML message as an event to WLI.

    4. Read an XML file from a local directory or from a remote FTP and post it as an event to WLI.

    Matt
  5. Yes, JBoss has an example in the 3.x docs. You have to buy it for 10$. Please check the JBoss.com site

    Jelle van Wieringen
  6. Used a version of POI 5 months ago. For some unknown reason, it inconsistently refused to read some Excel data fields. Neither could it detect the correct data type for some fields.

    Had the same problem with the JDBC-ODBC Bridge :-(

    Will Otemba solve my problem?

    Currently contemplating Data Junction, but USD 15K is rather expensive just to upload some data into an RDBMS.
  7. Thanks for asking. Could you send me the problem in isolated Java code? Please use my eMail address or the otemba site :

    http://sourceforge.net/tracker/?atid=487525&group_id=58379&func=browse
  8. It is not an Otemba problem.

    1) With JDBC-ODBC bridge:
    The problem is not with the code. If I create a new worksheet with the same data from scratch, or copy and modify from another worksheet, or copy and modify from the original template, the problem disappears (The cell can now be read). So, it has something to do with the bridge or Excel itself.

    2) With POI (version from 5 months ago):
    Same problem as JDBC-ODBC bridge. Additionally, it cannot detect the correct data-type for some cells. E.g. the cell is set to text and has a value like '99', but POI (or Excel) sometimes insists it is a number.

    The problem is the unpredictability. I can't ask the data-entry clerk to re-enter 20,000+ lines of data into a new worksheet or file because my code or its underlying library goes crazy.
  9. I can't ask the data-entry clerk to re-enter 20,000+

    > lines of data into a new worksheet or file because my
    > code or its underlying library goes crazy

    You could, but only of the clerk is really small and doesnt have a gun in her purse...
  10. Thank you for your feedback

    Otemba wraps the native Excel code, it does not intend to replace it as other projects do/aim

    pro:
    - local transaction level as defined in JCA 1.0
    - full logging in the JBoss environment
    - uses the native code of Microsoft, maintaines existing implementations (fi VB code)
    - the otemba API to excel will be stable in time whereas the microsoft code changes
    - clean memory management (that was the difficult part)

    con:
    - uses the native code of Microsoft, the otemba connections will dissolve themselves if anything breaks down. In this case a proper memory management prevails

    Jelle van Wieringen
  11. Otemba wraps the native Excel code


    Do you mean to say that I still need a Windows machine with Excel on it? If this is the case, does Otemba also need to reside on the same machine?

    TIA.
  12. Do you mean to say that I still need a Windows machine >with Excel on it? If this is the case, does Otemba also >need to reside on the same machine?


    >TIA.

    I must confess the otemba team has some documentation to do.

    Of course you need a windows machine, but it does not have to be the same machine.

    You will find an example in the JUnit test cases that uses the same machine. We will provide you more examples soon. These will show how to connect from any OS to a windows machine. I promise we will document all examples so that it will be clear what to do step by step.

    Please be aware that we have limited resources. From the numerous responses we will collect the requirements. From there on I suggest an XP appoach for our developing contributors.
  13. Java, Excel XLS documents[ Go to top ]

    I compiled a list of resources here:

    http://jinx.swiki.net/324