Page 1 of 2 12 LastLast
Results 1 to 10 of 17

Thread: ERP node helper library

  1. #1
    Contributor
    Join Date
    Mar 2008
    Location
    Boston, MA
    Posts
    106

    Default ERP node helper library

    NOTE:
    The attached erpAcquisitionHelpers library has been verified to be compatible with LAL released against LAE-6.1.3.
    It should work against other LAE-6.1.x versions but this has not been verified.
    Previous versions of the library have been left here, but have been renamed.
    The following libraries are attached:
    • erpAcquisitionHelpers.brg
      • Library to work against LAE-6.1.x releases (verified against LAE-6.1.3).

    • erpAcquisitionHelpers_51_60.brg
      • Library to work against LAE versions 5.1-6.0. (verified against LAE 6.0.

    • erpAcquisitionHelpers_2_19.
      • Library compatible with LAL 2.19.

    If you wish to use the attached prototype nodes, please ensure you choose the correct version of the file to use the erpAcquisitionHelpers.brg library
    .

    The Lavastorm Analytics Library 2.13 release introduces new nodes providing integration with the SAP Enterprise Resource Planning platform. To help users employ these nodes effectively, a library has been created which provides some utility nodes to assist in acquiring data from the SAP system. This material is provided as attachments to this post:
    • erpAcquisitionHelpers.brg - (see above to locate correct version to use)
    • SAP Prototype Nodes Getting Started.pdf - document which explains how to use these nodes.
    Please note that this library is offered in prototype state, and is not officially supported Lavastorm Analytics product. The functionality contained therein has not been developed using our standard practices and quality control, and any issues with this library will be managed using this forum only.
    Attached Files Attached Files
    Last edited by Tim Meagher; 08-16-2016 at 12:35 PM. Reason: 2015-07-02: Updating to add version that will work with LAL released against LAE 5.1+

  2. #2
    Lavastorm Employee
    Join Date
    Aug 2009
    Location
    Cologne
    Posts
    513

    Default

    The erpAquisitionHelpers library attached to the first post in this thread has been updated to be compatible with the new release of the Lavastorm Analytics Library - LAL 2.18.

    LAL 2.18 included a number of fixes and enhancements to the ERP nodes provided with the LAL releases.

    For further information see: http://community.lavastorm.com/threa...=5693#post5693

    A summary of the changes affecting the ERP nodes are:
    • The ERP Connector and Extract ERP Metadata nodes now both allow for Logon Load Balancing using a Group/Server connection. Issue 5418
    • The ERP Connector node has been enhanced to allow for executing a BAPI function multiple times based on its input data. Issue 5419
    • The ERP Connector node now has a new parameter "AdditionalParameterBehavior". This parameter defines the action to take when the node has inputs for scalar, structure or table import parameters which contains fields that do not exist on the corresponding function in the BAPI to execute. Issue 5420
    • The ERP nodes have a new parameter called "LargeDecimalAsDouble". This parameter allows the user to specify that even though the data may not fit into a double field, they want it to be output in such a field. Issue 5421

    While the nodes within the erpAquisitionHelpers library cannot execute multiple multiple times based on input data, all of the other changes to the ERP nodes mentioned above are reflected in the update to the erpAcquisitionHelpers library.
    This means that
    • The Extract ERP Table and Extract ERP Table Metadata nodes allow for Logon Load Balancing
    • The Extract ERP Table node has parameters "AdditionalParameterBehavior" and "LargeDecimalAsDouble
    In addition, a change has been made int the erpAcquisitionHelpers library to fix an issue whereby if the number of rows returned from a table query exceeded the RowBatchSize, the node could hang.

    Due to the addition of the Logon Load Balancing functionality, graphs configured using the existing library will need to be changed to set the "ConnectionType" parameter on the "Connection" tab.
    For nodes that were already working using the existing library, this parameter should be chosen as "Custom Application Server".

    Tim.

  3. #3
    Lavastorm Employee
    Join Date
    Aug 2009
    Location
    Cologne
    Posts
    513

    Default

    I've updated the library attached to the first post again.
    It is still compatible with LAL 2.18.

    The changes have been made to significantly improve performance on the Extract ERP Table node when extracting data from tables who's fields are larger than can be populated in the RFC_READ_TABLE call (default 512 bytes).
    Previously, the node would need to process small subsets of the data, executing the RFC_READ_TABLE function to extract each of the parts of the table before loading them into memory.
    Since the table data was loaded into memory, the number of records per extract needed to be small, resulting in many function calls.

    This no longer needs to be done.
    As such, the RowsPerExtract parameter has been removed from the node.

    Initial testing indicated a significant performance improvement, whereby extracting data from one of the tables (PA0006) on a SAP test system was previously taking 12 minutes, while it now takes 27 seconds on the same system.

    During testing, also investigated further the effect of the RowBatchSize parameter.
    By default this is 10,000.
    Increasing this to about 100,000 displayed significant performance improvements as well.
    Therefore, for optimal performance, this parameter can also be tweaked.
    However, setting this parameter too high will result in the SAP JCO code storing more records than it can allocate in memory, so care must be taken with this parameter to ensure that it doesn't exceed the memory restrictions on the node or of the system on which the node is running.

    Tim.
    Last edited by Tim Meagher; 02-26-2014 at 05:06 PM. Reason: Changed "RecordBatchSize" and "RecordsPerExtract" to "RowBatchSize" and "RowsPerExtract" to correctly match parameter names

  4. #4

    Default

    Hi,
    I have a question regarding extraction using ERP Table. Can I give (> and <) comparision operators in the OPTIONS section - for ex :- BEGDA > '20090101' and ENDDA < '99991231'. I get an error saying Dynamic conversion error.
    Also is it suggestable that we declare parameters and use them - parameter 1 = test and assign 20090101 to test and then give the filter BEGDA > 'test'.
    Regards
    Deepti

  5. #5
    Lavastorm Employee
    Join Date
    Aug 2009
    Location
    Cologne
    Posts
    513

    Default

    Hi,

    I have a question regarding extraction using ERP Table. Can I give (> and <) comparision operators in the OPTIONS section - for ex :- BEGDA > '20090101' and ENDDA < '99991231'. I get an error saying
    I'm not sure why that wouldn't work provided that the specified fields exist on the table.
    As far as I am aware, so long as these are date fields, and the format (yymmdd) is correct, and the syntax matches that which is expected by the OPTIONS parameter in the RFC_READ_TABLE function - which looks correct - then this should work.

    Also is it suggestable that we declare parameters and use them - parameter 1 = test and assign 20090101 to test and then give the filter BEGDA > 'test'.
    You can do this by creating a parameter "Test", setting the value of test to 20090101, then setting the OPTIONS parameter to:

    Code:
    BEGDA > '{{^Test^}}'
    Using standard parameter substitution available within the LAE.

    Regards,
    Tim.

  6. #6
    Lavastorm Employee
    Join Date
    Aug 2009
    Location
    Cologne
    Posts
    513

    Default

    Hi,

    I have updated the prototype library attached to the first post in this thread.

    The following changes have been made to the Extract ERP Table node:
    • The Options can now be provided either in the node directly, or via an input.
      • If provided directly then the Options drop-down box should be set to "Literal" and the value typed in the text box for the Options parameter
      • If provided via an input, then the Options drop-down box should be set to "Field" and then the name of the input field containing the Options should be typed in the text box for the Options parameter
      • When processing Options from an input pin, the RFC_READ_TABLE function is executed once per input record
      • Existing graphs which were using the Options written directly in the parameter will need to be modified to specify that this is a "Literal" in the Options drop-down box.
    • An additional parameter "RowCountPerOption" has been added.
      • If specifying Options from an input pin, this parameter determines whether the RowCount parameter applies as an overall limit on the number of records to return, or a limit per input record (and therefore, per execution of the RFC_READ_TABLE function)
    • Fixed an issue whereby negative values returned from RFC_READ_TABLE were not handled correctly. (These were being returned with a trailing "-" which wasn't parsed correctly by the node)
    • Added a parameter "OutputRecordNumbers" to control whether or not the node write record numbers on the Data, Error Details and Error Records outputs
    In addition, the documentation for the node has been updated in the attached pdf file.
    While it may work against earlier LAL versions, it has been developed against the LAL 2.19 release, so LAL 2.19 or greater should be used.

    The underlying implementation of the Extract ERP Table node is now a single node rather than a composite in order to implement these changes.
    This should just work with existing graphs.
    However, it may be that not all output handles were fixed correctly, so when upgrading to the newer prototype library, you may need to rewire the node's connections.

    Regards,
    Tim.

  7. #7
    Lavastorm Employee
    Join Date
    Aug 2009
    Location
    Cologne
    Posts
    513

    Default

    The helper library attached to the first post has again been updated.

    A fix has been added to ensure that the Extract ERP Table node can handle "Options" values which have a length greater than 72 characters.
    The default RFC_READ_TABLE implementation imposes a 72 byte character limit on the TEXT field in the OPTIONS table parameter.
    The node will now split up the Options parameter if it is too large, to ensure that each TEXT field in the OPTIONS table parameter doesn't take up more than 72 characters.
    These options are still sent in the one table parameter to SAP, so they will still be applied as if they were in a single field in a single record.
    This splitting is done in a way to ensure that it only starts a new record on "AND" or "OR" conditions in the OPTIONS clause (and ensures that these are not occurring within single-quotes).

    The node will now provide sensible error messages in such cases where single quotes don't match, or if the Options parameter cannot be split into parts which are all < 72 characters in length.

  8. #8

    Default

    Hi,

    I'm experiencing a weird issue with option parameter in extract ERP table node.

    I'm extracting table EBEW for selected plants (BWKEY field). I can trigger the issue in multiple SAP environments in multiple tables but most of times I don't run into this issue.

    Setting the option as literal:
    1) BWKEY = 'AAA' OR BWKEY = 'BBB' -> works ok
    2) BWKEY = 'BBB' OR BWKEY = 'AAA' -> works ok (just like the first onel but reversed plant order)
    3) BWKEY = 'AAA' -> works ok
    4) BWKEY = 'BBB' -> works ok
    -> I have no issues at all when using literal mode for table options

    Setting the option as field (option type: Field, field name: Options) :

    Options:unicode
    BWKEY = 'AAA'
    BWKEY = 'BBB'
    -> works ok

    Options:unicode
    BWKEY = 'BBB'
    BWKEY = 'AAA'
    ->this order does not work in my scenario so theres a difference whether AAA or BBB comes first in the static data node containing the options.

    As I don't have any issues at all with literal options with exactly the same option setup there shouldn't be a chance the issue could be on the SAP side (data related issue/connection related issue) but that the issue must be in the where clause generation when using Field as option type in the node. Is there a way to see the final where clause that is generated by the node/sent to the SAP from the logs?

  9. #9
    Lavastorm Employee
    Join Date
    Aug 2009
    Location
    Cologne
    Posts
    513

    Default

    Hi,

    I'll try and investigate this with you further via email and share any insights gained at the end via this forum.
    It certainly is a strange problem.
    Regarding the last question, the "where" clause is actually a table parameter that is provided to SAP.
    Each record in the table parameter can be seen in the log if you set the LogLevel to 0 -you will see log entries with:

    Option Part: <OPT>

    Where <OPT> contains the actual string which is set as the field in the table parameter and then sent to the SAP function.

    Tim.

  10. #10

    Default

    Hi,

    Is erpAcquisitionHelpers.brg compatible with LAE 5.0 and LAL 5.0?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •