Working with the ERP nodes - Latest

Extract ERP Metadata examples

The two most common use cases for the Extract ERP Metadata node is to search for the names of functions matching a specified pattern, or to extract all of the metadata for a specific function. The following two examples show how these operations can be performed:

For more details on configuring this node, see the node help page Extract ERP Metadata.

Searching for a function

To search for a function that matches a specific pattern, configure the node properties, as follows:

• FunctionName - set to the pattern that you want to match.
• FunctionMatchMethod - set to Regular Expression or Glob Pattern, depending on how you are searching.
• CaseSensitive - if you want to match case-insensitively, set this to False.
• FunctionNamesOnly - set this to True to ensure that only the function names, and not all interface information, is returned for all matched functions.

You want to find all of the BAPI functions which are related to handling bank details. If you know that the functions you care about all contain the string "_BANK_", but aren't sure of the function names, and aren't sure whether this "_BANK_" string needs to be uppercase, you could configure the node as follows:

• FunctionName - Set to the glob-pattern *_BANK_*
• FunctionMatchMethod - Select Glob Pattern.
• CaseSensitive - Select False to perform a case-insensitive glob pattern match.
• FunctionNamesOnly - Select True to return only function names. This means that the Scalar Parameters, Structure Parameters and Tables outputs will have no records. On the Functions output all of the functions that match this pattern are output:

Extracting metadata for a specific RFM

To extract the metadata for a specific function, set the node properties as follows:

• FunctionName - set to the exact name of the function that you want to match.
• FunctionMatchMethod - set to Exact (or leave empty, as Exact is the default).
• CaseSensitive - set to True (or leave empty, as true is the default).
• FunctionNamesOnly - set to False (or leave empty, as False is the default), to ensure that all interface information is returned for the function.

In the first example, we located all of the functions that deal with "_BANK_" information. If we now wanted to execute the "BAPI_BANK_GETLIST" function, we would first need to extract the metadata information, or the interface for this BAPI.

To do this, set the FunctionName property to BAPI_BANK_GETLIST and run the node.

Since in this case, we have extracted all of the function interface information and not the function name only, you will see that all of the outputs have records.

The Functions output will simply contain a single record matching the function whose metadata we have extracted – the same record that was part of the Functions output displayed in the previous example.

Investigating the Scalar Parameters output shows that there are two import scalar parameters (parameters that need to be provided when executing the function), a string/Unicode field "BANK_CTRY", and an integer field "MAX_ROWS":

Investigating the Structure Parameters output shows that there is just one structure export parameter "RETURN". "RETURN" is the standard export structure used by BAPIs to return error information. The records returned on the Structure Parameters output are shown below:

The Tables output shows that the BAPI_BANK_GETLIST defines just one table "BANK_LIST". While the interface does not define whether a table parameter is an export or import parameter, since the function is a "GETLIST" function, and since the only table defined is a "BANK_LIST" it is reasonable to assume that this is an export parameter.

The records returned on the Tables output are as follows:

ERP Connector examples

For more details on configuring this node, see the node help page ERP Connector.

Example 1 - Create

Consider the case where we want to create a new Bank object in the SAP system. First, we need to locate the correct BAPI to execute and its interface. In the example Searching for a function, we can see that there exists a BAPI on the system called "BAPI_BANK_CREATE". To determine the interface, we can therefore run the Extract ERP Metadata node with the following configuration:

• FunctionName - Type BAPI_BANK_CREATE
• FunctionMatchMethod - Select Exact
• CaseSensitive - Select False
• FunctionNamesOnly - Select False

Investigating the Scalar Parameters output shows that it defines the following scalar parameters:

Of these, only the BANK_CTRY parameter is a required import parameter. Therefore, on the ERP Connector node, we can already enter the FunctionName as "BAPI_BANK_CREATE" and in ScalarParameters, enter the value:

BANK_CTRY=US

As this example was run against a system which was not correctly configured , a "BANK_KEY" was also required, and provided as:

BANK_KEY=0001

SAP documentation indicates that if the internal number assignment is not defined for the bank country, then the bank key is required. Since this example was executed on a test system without these internal numer assignment setup for the countries, providing the bank key was necessary.

We then move onto the Structure Parameters output of the Extract ERP Metadata node, which shows the import structures "BANK_ADDRESS" and "BANK_ADDRESS1" along with the export structure "RETURN".

Of these, however, only the "BANK_ADDRESS" structure is a required import structure. The details of this import structure are shown below:

Therefore, we can setup the StructureParameters property on the node to specify the structure parameters. Further investigation of documentation revealed that not all parameters are required on the structure, therefore only the following were configured in the StructureParameters property:

BANK_ADDRESS.BANK_NAME=My New BankBANK_ADDRESS.REGION=MABANK_ADDRESS.STREET=100 State StreetBANK_ADDRESS.CITY=BostonBANK_ADDRESS.SWIFT_CODE=MYNBUS3N

Finally, the CommitTransaction property was set to true as this is a create operation which requires the transaction to be committed in order for it to take effect.

The outputs then need to be configured. The "Scalar Parameters" and "Structure Parameters" output from the Extract ERP Metadata node shows that the node exports a "RETURN" structure and the scalar parameters "BANKCOUNTRY" and "BANKKEY". Therefore, in order to ensure that this return structure, and the scalar parameters are output, the outputs "Scalar Parameters" and "Structure Parameters_RETURN" are constructed on the node.

This leads to the following node configuration, where both the CommitTransaction and CoerceInputData properties are set to True:

• FunctionName - BAPI_BANK_CREATE
• ScalarParameters - BANK_CTRY=USBANK_KEY=0001
• StructureParameters - BANK_ADDRESS.BANK_NAME=My New BankBANK_ADDRESS.REGION=MABANK_ADDRESS.STREET=100 State StreetBANK_ADDRESS.CITY=BostonBANK_ADDRESS.SWIFT_CODE=MYNBUS3N
• DeactivateExportParameters - 1

After running the node, you will see that it returns the BANKCOUNTRY and BANKKEY on the Scalar Parameters output pin, as follows:

Investigation of the Structure Parameters_RETURN shows that the node did not return anything that indicated an error had occurred in executing the BAPI.

Example 2 - Read

We now want to check that the bank in the previous example was successfully created. In order to do so, we first run the BAPI_BANK_GETLIST function. The BAPI_BANK_GETLIST function requires two scalar import parameters "BANK_CTRY" and "MAX_ROWS", see Extracting metadata for a specific RFM. For some reason the API defines these as both required, however some investigation shows that MAX_ROWS is not actually required.

We also saw that the BAPI_BANK_GETLIST has an export structure parameter "RETURN" along with an export table "BANK_LIST", see Extracting metadata for a specific RFM. Therefore, we construct the node to have the outputs "Structure Parameters_RETURN" "BANK_LIST". Since we want to extract the bank list for the country within which we created the bank in the previous example, we set the "BANK_CTRY" scalar parameter to "US".

After performing these steps, the configured node appears as follows:

• FunctionName: BAPI_BANK_GETLIST
• CommitTransaction: Default
• CoerceInputData: True

Note that since we are not making a modification to the system (i.e. this is a read operation, not a create, update or delete) we do not need to set the CommitTransaction property to True.

After running the node, the "Structure Parameters_RETURN" output shows no errors, and amongst the banks in the "BANK_LIST" output is the bank we created in the previous step, as follows:

Example 3 - Update

Consider the case that we made an error in constructing the bank information in the previous section. In such cases, we may want to use an update function to modify an existing object in the SAP system. When looking at the different BAPI_BANK_* functions (see Searching for a function) you can see that the mechanism to do this would be using the BAPI_BANK_CHANGE function.

Most BAPI update functions (those ending in "_CHANGE") take a "value" import structure specifying the new field values, and a "flag" structure which has the format "<valueimportStructureName>X" specifying which fields from the "value" import structure are to be modified. For the BAPI_BANK_CHANGE function, you can see there are the following structures:

• BANK_DETAIL, BANK_DETAILX
• BANK_ADDRESS, BANK_ADDRESSX
• BANK_ADDRESS1, BANK_ADDRESS1X

Therefore, if we needed to modify the "STREET" field in the BANK_ADDRESS structure to change from "100 State Street" to "105 State Street", we could populate the two Structure Parameters:

• BANK_ADDRESS.STREET=105 State Street
• BANK_ADDRESSX.STREET=X

This then tells the BAPI_BANK_CHANGE function to modify the STREET field to the new value.

In order to do this, we configure the node as follows:

• FunctionName: BAPI_BANK_CHANGE
• ScalarParameters:BANKCOUNTRY=USBANKKEY=0001
• StructureParameters:BANK_ADDRESS.STREET=105 State StreetBANK_ADDRESSX.STREET=X
• CommitTransaction:False
• CoerceInputData:True

Note that the CommitTransaction property has been set to False, since this function needs to modify data on the SAP system.

Example 4 - Delete

While the other examples investigated so far have dealt with the BAPI_BANK_* set of BAPIs, no corresponding "Delete" BAPI was found on this system. Therefore, in order to test the "Delete" functionality, we'll use the BAPI_USER_DELETE function.

In order to see which BAPIs are available for the USER object, first run the Extract ERP Metadata node with the "FunctionName" parameter set to "BAPI_USER_*", using a "FunctionMatchMethod" of "GlobPattern", and "FunctionNamesOnly" set to true.

This results in the "Functions" output from the node as shown below:

As shown above, there are numerous BAPI_USER_* functions, including one for deleting users "BAPI_USER_DELETE".

We don't want to delete just any user from the SAP system, so we will first create a dummy user that we will later delete. In order to do this, first examine the metadata for the BAPI_USER_CREATE function – again using the Extract ERP Metadata node.

Since this is a dummy account, it makes sense to only look at the import parameters that are required. From this, we see that the only required scalar import parameter is a "USERNAME". The required import structures are "ADDRESS", "LOGONDATA", and "PASSWORD".

While these structures are required, not all parameters on the structures will be required. Therefore, we'll attempt to create a dummy user with as little information as possible. N order to do this, insert an ERP Connector node with the following configuration:

• FunctionName: BAPI_USER_CREATE
• ScalarParameters: USERNAME=Dummy

• StructureParameters:

  ADDRESS.PERS_NO=0000010899ADDRESS.ADDR_NO=0000010900ADDRESS.TITLE=MrADDRESS.FIRSTNAME=DummyADDRESS.LASTNAME=UserADDRESS.FULLNAME=Dummy UserADDRESS.NAMCOUNTRY=USADDRESS.LANGU_P=EADDRESS.DEPARTMENT=EngineeringADDRESS.FLOOR=5ADDRESS.CITY=BostonADDRESS.DISTRICT=BostonADDRESS.POSTL_COD1=02210ADDRESS.STREET=Summer StreetADDRESS.COMM_TYPE=RMLADDRESS.STREET_NO=321ADDRESS.COUNTRY=USADDRESS.COUNTRYISO=USADDRESS.LANGU=EADDRESS.LANGU_ISO=ENADDRESS.TIME_ZONE=GMTCOMPANY.COMPANY=Dummy CompanyLOGONDATA.GLTGV=2013-01-01LOGONDATA.GLTGB=2016-01-01LOGONDATA.USTYP=ALOGONDATA.CODVN=BLOGONDATA.CODVC=FPASSWORD.BAPIPWD=abcd1234

• CommitTransaction: True

There are no export parameters that we care about, so no outputs need to be configured. Once the above configuration has been entered, execute the node.

In order to verify that the user has been successfully created, use the BAPI_USER_EXISTENCE_CHECK function. This function simply requires a scalar import parameter "USERNAME", and an export structure "RETURN". Therefore, the configuration of the ERP Connector node to execute the function is relatively trivial and is as follows:

• FunctionName:BAPI_USER_EXISTENCE_CHECK
• ScalarParameters:USERNAME=Dummy
• CommitTransaction:Default
• CoerceInputData:Default

If the user has successfully been created, in the output of the "Structure Parameters_RETURN", you will see that the "MESSAGE" field contains the text:

User DUMMY exists

Now that the dummy user exists, it can be deleted.

The BAPI_USER_DELETE function is similarly trivial. It requires only one scalar import parameter "USERNAME" – specifying the name of the user who is to be deleted. It has only one exported table "RETURN".

Therefore, to delete the user in question, all you need to do is insert an ERP Connector node, with the "Scalar Parameters" set to:

USERNAME=Dummy

As this is a modification operation, the CommitTransaction property should be set to True.

An output "RETURN" should also be added to the node.

If the node runs successfully, and the user has been successfully deleted, you will see three records in the "RETURN" output, with the following information in the "MESSAGE" field:

Role assignment to user DUMMY deletedProfile assignment for user DUMMY was deletedUser DUMMY deleted

In order to verify that these messages accurately reflect the state of the system, run the BAPI_USER_EXISTENCE_CHECK function again, checking for user "DUMMY". In this case, in the "MESSAGE" field of the "Structure Parameters_RETURN" output, you will see:

User DUMMY does not exist

This indicates that the user has been successfully deleted and no longer exists on the system.

Example 5 - Parameters from node inputs

We now want to check that the change we performed on the bank details in the the previous example (BAPI_BANK_CHANGE) was successfully committed. To do so, we run the BAPI_BANK_GETDETAIL function.

If we run the Extract ERP Metadata node, we'll see that there are two scalar import parameters: BANKCOUNTRY and BANKKEY. The bank created in the previous section had a coutry code of "US" and a key of "0001".

Rather than specifying these in the node's ScalarParameters property, however, this time we'll pass these values into the node in an input pin. To do this, configure the Data property of a Create Data node as follows:

BANKCOUNTRY:string,BANKKEY:string

US,0001

Then, create a "Scalar Parameters" input on the ERP Connector node and connect the output of the Create Data node to the input of the ERP Connector node.

Set the FunctionName property to BAPI_BANK_GETDETAIL.

Since the BAPI defines three export structure parameters "BANK_DETAILS", "BANK_ADDRESS" and "RETURN", construct three corresponding outputs on the node "Structure Parameters_BANK_DETAILS", Structure Parameters_BANK_ADDRESS" and "Structure Parameters_RETURN".

Then run the node.

After running the node, you'll see in the "Structure Parameters_BANK_ADDRESS" output, the data shown below, indicating that the update performed in the previous section was performed successfully:

Example 6 - Providing table inputs

Generally, BAPIs do not take table parameters as import parameters. However, in some cases they do, and some RFCs also take import table parameters. In this example, we'll show how to construct a node which takes two table import parameters to execute the function RFC_READ_TABLE.

First, run the Extract ERP Metadata node, extracting the metadata for the "RFC_READ_TABLE" function. The scalar parameters defined on the RFC_READ_TABLE function are shown below:

Investigation into the function reveals that it will extract all fields from the source table into a single output field.

Scalar import parameters information:

• DELIMITER
  • If specified, the returned data will contain a delimiter between each of the fields in the source table that are extracted to the destination "WA" field.
  • The fields are extracted as fixed width, however, and no escape character is used, so use of a delimiter does not necessarily make it easier to reconstruct the original field values.
• NO_DATA
  • If set, only the metadata is extracted.
• QUERY_TABLE
  • Name of the table to extract.
• ROWCOUNT
  • Number of rows to extract.
• ROWSKIPS
  • Number of rows to skip prior to extracting the data from the table.

There are no structure parameters for the function, however there are three table parameters as shown below:

In this case, further investigation of the function online reveals that while all of these tables can be provided as both import and export parameters, the intended use is that the "OPTIONS" table can be provided as an import table parameter in order to essentially perform the equivalent of a "WHERE" clause of a query.

The "FIELDS" table when provided as an import table parameter is used to restrict the fields that are extracted from the table (like the SELECT part of a query). In this case, only the FIELDNAME field is are considered, and the other fields within the "FIELDS" table are ignored. When used as an export table parameter, this will return the information on the fields in the table. The "DATA" table is designed to be used for export only and all of the extracted fields are dumped to the "WA" field in the "DATA" table.

Using this information, we can construct an ERP Connector node to simply extract the field metadata from the table "DBCON" as shown below:

• FunctionName:RFC_READ_TABLE
• ScalarParameters:QUERY_TABLE=DBCONNO_DATA=X
• CommitTransaction:Default
• CoerceInputData:Default

Once this is done, we can then construct a node which will read the data from that table using the field information returned from this call, shown below:

First, consider the case where we only want to extract the CON_NAME, DBMS, USER_NAME and MAX_CONNECTIONS fields. Then, we could construct a Create Data node which specifies each of these to be provided as the table import parameter "FIELDS" as follows:

• Rename the Create Data node as FIELDS
• In the Data property, enter the following:FIELDNAME:unicodeCON_NAMEDBMSUSER_NAMEMAX_CONNECTIONS

If we wanted to only extract data where the CON_NAME field equals NSP and the USER_NAME field is SAPNSP, we could configure the OPTIONS table import parameter definition using a Create Data node as follows:

• Rename the Create Data node as OPTIONS
• In the Data property, enter the following:TEXT:unicodeCON_NAME = 'NSP' AND USER_NAME = 'SAPNSP'

Once this is done, we can create an OPTIONS and a FIELDS input to the ERP Connector node to accept these table import parameters and configure the node with "FIELDS" and "DATA" outputs to extract the field metadata information and the data from the table.

Then, with the scalar import parameter "QUERY_TABLE" set to "DBCON", and the scalar import parameter "NO_DATA" not set, running the node will yield the "FIELDS" and "DATA" outputs shown below.

FIELDS output for configured RFC_READ_TABLE:

DATA output for configured RFC_READ_TABLE:

Extract ERP Table Metadata example

To extract the table metadata for the a table named "DBCON", enter DBCON in the TableName property.

The node outputs the metadata for the "DBCON" table, for example:

For more details on configuring this node, see the node help page Extract ERP Table Metadata.

Extract ERP Table examples

For more details on configuring this node, see the node help page Extract ERP Table.

Example 1 - Extracting a whole table

To extract a whole table using the Extract ERP Table node, provided that the table contains no fields that exceed the byte limit of the RFC_READ_TABLE function, you only need to specify the table name in the TableName property.

To extract a table named "DBCON", enter DBCON in the TableName property.

The node outputs the table information, for example, the following table shows the data on the Fields output pin:

Note that while no individual field is longer than 512 bytes, each record is longer than 512 bytes. For this reason, the node is performing multiple calls to RFC_READ_TABLE with a subset of the total number of fields to ensure that the data returned by the call does not exceed the 512 byte limit of RFC_READ_TABLE.

The Data output shows that the fields have been correctly extracted and formatted into corresponding output fields:

Example 2 - Extracting specific fields and records

This example illustrates how to locate the first 100 fields defined in the SAP system that are of a "date" type. This is done by checking the table named "DD03L" which defines the fields for all of the SAP tables.

1. To locate only the first 100 records, type 100 in the RowCount property.
2. To ensure that we only get fields of type "date", in the Options property type INTTYPE = 'D'.
3. If you only want the table name, field name, and data type, in the Fields property type TABNAME,FIELDNAME,INTTYPE.

The Data output shows only 100 records and each of the fields have a 'D' type.