Cardinality

Dear all ,
I have a question here about the joins cardinality in OBIEE. There is join in the fact and dimension table as 1;N .If I have changed this as N;1 will it give nay change in the results .
What is the pupose of the cardinality in OBIEE ,how this will give result diff in out out of the report .
Thanks

Before Tuning:
COST CARDINALITY BYTES
SELECT STATEMENT, GOAL = ALL_ROWS               40     126     17010
HASH GROUP BY               40     126     17010
NESTED LOOPS               39     133     17955
NESTED LOOPS               4     1     93
NESTED LOOPS               3      1     81
TABLE ACCESS BY INDEX ROWID     OPR     FUND     2     1     42
INDEX UNIQUE SCAN     OPR     SYS_C00113947 1     1     1
TABLE ACCESS BY INDEX ROWID     OPR     FUND_GROUP     1     265     10335
INDEX UNIQUE SCAN     OPR     SYS_C00113949 1     0     1
TABLE ACCESS BY INDEX ROWID     OPR     FUND_CAT     1     3     36
INDEX UNIQUE SCAN     OPR     SYS_C00113947 6     0     1
TABLE ACCESS BY INDEX ROWID     OPR     FUND_SUBTYPE     35     133     5586
INDEX RANGE SCAN     OPR     XIF14 FUND_SUBTYPE     1     133

Similar Messages

Cardinality estimator 2014 is off with OR in where clause

Here is my test setup on SQL Server 2014.
-- Create big table
CREATE TABLE [dbo].[Store](
Id int IDENTITY(1,1) NOT NULL,
City int NOT NULL,
Size int NOT NULL,
Name varchar(max) NULL,
CONSTRAINT [PK_Store] PRIMARY KEY CLUSTERED ([Id] ASC)
GO
CREATE NONCLUSTERED INDEX [IX_Store] ON [dbo].[Store] (City ASC, Size ASC)
GO
-- Fill with 100k rows
INSERT Store
SELECT i % 101, i % 11, 'Store ' + CAST(i AS VARCHAR)
FROM
(SELECT TOP 100000 ROW_NUMBER() OVER (ORDER BY s1.[object_id]) AS i
FROM sys.all_objects s1, sys.all_objects s2) numbers
GO
-- Create small table
CREATE TABLE #StoreRequest (City int NOT NULL, Size int NOT NULL)
GO
INSERT #StoreRequest values (55, 1)
INSERT #StoreRequest values (66, 2)
Now I execute the following query (I force the index to show statistics estimates)
SELECT s.City
FROM #StoreRequest AS r
INNER JOIN Store AS s WITH(INDEX(IX_Store), FORCESEEK)
ON s.City = r.City AND s.Size = r.Size
WHERE s.Size <> 1 OR r.City <> 55
Here are the estimates that I get (I'm not allowed to upload pictures):
Index Seek IX_Store
Actual Number of Rows: 90
Estimated Number of Rows: 50000
Fixing WHERE clause to use one table not two makes the estimate perfect:
SELECT s.City
FROM #StoreRequest AS r
INNER JOIN Store AS s WITH(INDEX(IX_Store), FORCESEEK)
ON s.City = r.City AND s.Size = r.Size
WHERE s.Size <> 1 OR s.City <> 55
Index Seek IX_Store
Actual Number of Rows: 90
Estimated Number of Rows: 89.74
Switching to 2012 compatibility mode gives estimate of 1 in both cases:
Index Seek IX_Store
Actual Number of Rows: 90
Estimated Number of Rows: 1
Could anyone explain the first result? I'm a bit worried about it. The fix in this case is trivial, but this problem gave us quite some headache in more complex real life queries with multiple joins.
Thank you!

But not full statistics on a field basis, just sometimes some default stats like total row count that some plans will build. Even your StoreRequest table only has one two-field index that will have a full histogram.
But I've seen SQL Server make massively bad plans on two-field indexes.
I've seen SQL Server go wrong one-column indexes, so that is not a very relevant point.
Temp tables or not, the estimate here is clearly incorrect. SQL Server knows the density of Size and City. It knows the cardinality of the temp table. The density information gives how many rows the the join will produce. The WHERE clause will then remove
a certain number of rows. With no statistics for the temp table, it does not now how many, but it will apply some standard guess.
50000 is a completely bogus number, because the join cannot produce that many rows, and SQL Server is able to compute the join with out the WHERE clause decently. (Well, it estimates 90, when the number is 180.) No, this is obviously a case of the cardinality
estimator giving up completely.
It is worth noting that both these WHERE clauses gives reasonable estimates:
WHERE r.Size <> 11 OR r.City <> 550
WHERE s.Size <> 11 OR s.City <> 550
Whereas these two gives the spooky 50000:
WHERE s.Size <> 11 OR r.City <> 550
WHERE r.Size <> 11 OR s.City <> 550
Erland Sommarskog, SQL Server MVP, [email protected]

What is line item dimension and cardinality in BI 7.0

Can u plz suggest me what is line item dimension and cardinality in BI 7.0..
Thanks in advance.
Venkat

Hi Babu
Line item: This means the dimension contains precisely one characteristic. This means that the system does not create a dimension table. Instead, the SID table of the characteristic takes on the role of dimension table. Removing the dimension table has the following advantages:
¡ When loading transaction data, no IDs are generated for the entries in the dimension table. This number range operation can compromise performance precisely in the case where a degenerated dimension is involved.
¡ A table- having a very large cardinality- is removed from the star schema. As a result, the SQL-based queries are simpler. In many cases, the database optimizer can choose better execution plans.
Nevertheless, it also has a disadvantage: A dimension marked as a line item cannot subsequently include additional characteristics. This is only possible with normal dimensions.
Note: In SAP BW 3.0, the term line item dimension from SAP BW 2.0 must a) have precisely one characteristic and b) this characteristic must have a high cardinality. Before, the term line item dimension was often only associated with a). Hence the inclusion of this property in the above. Be aware that a line item dimension has a different meaning now than in SAP BW2.0.
SAP recommends that you use ODS objects, where possible, instead of InfoCubes for line items.
Hope this helps.
Plz check these links:
SAP Help:
http://help.sap.com/saphelp_nw04s/helpdata/en/a7/d50f395fc8cb7fe10000000a11402f/frameset.htm
Thanks & Regards
Reward if helped
Edited by: Noor Ahmed khan on Aug 5, 2008 2:36 PM

Error while initiating Wily agent on SMD node of cardinality

Hi
I am not sure if I have to put this question here but anyways:
I have deployed wily agent thru JSPM and when tried to initiate it on SMD i get this error:
500 Internal Server Error
The initial exception that caused the request to fail, was:
com.sap.tc.webdynpro.progmodel.context.ContextException: Node(WilyAdmin.EMS): must not bind an empty collection to a Node of cardinality 1..1 or 1..n
Please suggest what can I do

Hi Bill,
I'm facing the same issue, did you resolve it?? If yes, how did you??
Best regards and thanks,
María Margarita Monteverde

Line Item Dimention Vs Hig Cardinality

HI ALL
           I have a problem with a cube and the below are the challenges...
                   1) can we use High cardinality / line item dimension if we already used one of these(High cardinality / line item dimension)?
                   2) while loading 4lakh records in to cube, i tried optimizing the cube by segregating characteristics into different dimension and i am successful in bringing down the percentage levels but all dimension levels are almost near to 30%. I Have only 1 key figure , will it cause any problem....
         please let me know the concept....
Thanks
vijay

Hi Vijay,
High Cardinality Purpose: If data volume stored in a table is very huge, it's difficult to retrieve particular record or sets of records. For fast retrieval purpose system creates Indexes on various columns, by default SAP BW creates 'Bitmap' index on each dimension.
If dimension doesn't contains large number of distinct values 'Bit Map Indexes' are fine, but in case distinct values are high and the dimension table is at least 20% of the size of the fact table, SAP recommends checking the 'High Cardinality' check box to create 'B-Tree' indexes. When compared to Bitmap indexes B-Tree indexes data retrial is fast, this is recommended on Oracle Data base.
Line Item Dimension: By checking this the relational path of Fact Table -> Dim_ID -> SID will be reduced to Fact -> SID, so you must create a dimension which doesn't create more relations between included characteristics in dimension.
So you can check Line Item dimension to make the system aware of not creating the Dim_ID path and you can check the High Cardinality to make the system to generate B-Tree indexes.
Hope this helps.
Regards
-Sunil

How to manage a node with cardinality 0..n

hi,
i implemented a application with webdynpro which uses a sap babi. everything wents fine, except that i don't know which container i have to use for a cardinality 0..n. one node has this and so the attributes can entered as often as possible.
but i only need one string, so i tried it with an input field, but this is greyed out. what have i to do?

Hi Marcus,
If there is no way you could change the cardinality of the node, and thus it can contain 0..n items, I think you should create-and-add a new element programmatically.
Since the collection can contain zero elements, I would add a 'new' button, which upon clicking adds one new element via:
IYourNodeElement yourNodeElem = wdContext.nodeYourNode().createYourNodeElement();
wdContext.nodeYourNode().addElement(yourNodeElem);
Hope this explains a bit!
Best,
Robin van het Hof

Dynamic form in Webdynpro for ABAP - Context Cardinality question

Hello -
I have an adobe form in a webdynpro for ABAP application which I want to be able to be dynamic. Basically I want to be able to use a Webdynpro context node with a cardinality of 1-N and the form will take each node of the context and create a page for each one. I am able to do a static form with a context node that has a 1-1 cardinality, but once I change my cardinality to 1-N on the node the static form no longer works (there is no data). Is what I want to do possible? I've looked through all the documentation I could find and could not get a definite answer. Any help would be appreciated.
Widget (1-N)
     -Widget_info (1-1)
          *Name
          *Sku
          *Description
     -Widget_plant (1-M)
          *Plant_Code
          *Plant_State
          *Plant_City
     -Widget_pic (1-1)
          *Picture
... So I want to have a form which can print a page for each widget in the context (the number of which can vary). That form would have the Name, sku, description, plant_code, plant_state, plant city and the picture on it. (This is just a generic example of what I need to do)
Regards,
- Jason

Ok, I think I found a bug... It seems for adobe forms in WD4A, the root context node must be 1-1 and you must nest the 1-n node within that... Not sure why, but it worked. So in my case my context would look like this:
FOO_NODE (1-1)
     Widget (1-N)
          -Widget_info (1-1)
               *Name
               *Sku
               *Description
          -Widget_plant (1-M)
               *Plant_Code
               *Plant_State
               *Plant_City
          -Widget_pic (1-1)
               *Picture

Cardinality explosion with several XMLTable calls in one query - how to constrain ?

Hi,
when I engage several (say, four) XMLTable calls using comma (= cartesian join) in a single query, the plan shows me insane cost of 15 digits. Though execution time is reasonable because XML document is very small, I would like the plan appear with more realistic values to correctly predict query time when XML document becomes larger. How can I make CBO be aware of actual size of XML text?
Should I use XML indexing to constrain search space? What are the 'best practices' in indexing XML text for efficient parsing by XMLTable?
SQL> select * from v$version;
BANNER
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
PL/SQL Release 11.2.0.3.0 - Production
CORE    11.2.0.3.0      Production
TNS for Linux: Version 11.2.0.3.0 - Production
NLSRTL Version 11.2.0.3.0 - Production
Thanks for your answers!

Hi,
Thanks, odie_63. I used index to give CBA an idea of cardinality.
So, the original plan is (P=Peta, T=Tera, etc...):
Plan hash value: 954188411
| Id | Operation             | Name        | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT      |             | 4451T| 5099P|    14T (1)|999:59:59 |
|   1 | NESTED LOOPS         |             | 4451T| 5099P|    14T (1)|999:59:59 |
|   2 |   NESTED LOOPS        |             |   544G|   638T| 1816M (1)|999:59:59 |
|   3 |    NESTED LOOPS       |             |    66M|    79G|   222K (1)| 00:44:34 |
|   4 |     NESTED LOOPS      |             | 8168 |     9M|    32   (0)| 00:00:01 |
|   5 |      TABLE ACCESS FULL| XML_DROPBOX |     1 | 1252 |     3   (0)| 00:00:01 |
|   6 |      XPATH EVALUATION |             |       |       |            |          |
|   7 |     XPATH EVALUATION |             |       |       |            |          |
|   8 |    XPATH EVALUATION   |             |       |       |            |          |
|   9 |   XPATH EVALUATION    |             |       |       |            |          |
Note
   - Unoptimized XML construct detected (enable XMLOptimizationCheck for more information)
After creating an index, like:
CREATE INDEX XML_DROPBOX_IDX ON XML_DROPBOX (SYS_NC_ROWINFO$)
INDEXTYPE IS XDB.XMLINDEX PARAMETERS (
'PATH TABLE XML_DROPBOX_PATH_IDX (NOLOGGING ENABLE ROW MOVEMENT)
   PATH ID INDEX XML_DROPBOX_PATH_ID_IDX (NOLOGGING)'
the plan become more voluminous, but shows realistic cost:
Plan hash value: 1726871192
| Id | Operation                          | Name                    | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT                   |                         |     1 | 10666 |     9   (0)| 00:00:01 |
|* 1 | FILTER                            |                         |       |       |            |          |
|* 2 |   TABLE ACCESS BY INDEX ROWID      | XML_DROPBOX_PATH_IDX    |     1 | 3524 |     2   (0)| 00:00:01 |
|* 3 |    INDEX RANGE SCAN                | XML_DROPBOX_PATH_ID_IDX |     1 |       |     1   (0)| 00:00:01 |
|* 4 | FILTER                            |                         |       |       |            |          |
|* 5 |   TABLE ACCESS BY INDEX ROWID      | XML_DROPBOX_PATH_IDX    |     1 | 3524 |     2   (0)| 00:00:01 |
|* 6 |    INDEX RANGE SCAN                | XML_DROPBOX_PATH_ID_IDX |     1 |       |     1   (0)| 00:00:01 |
|* 7 | FILTER                            |                         |       |       |            |          |
|* 8 |   TABLE ACCESS BY INDEX ROWID      | XML_DROPBOX_PATH_IDX    |     1 | 3524 |     2   (0)| 00:00:01 |
|* 9 |    INDEX RANGE SCAN                | XML_DROPBOX_PATH_ID_IDX |     1 |       |     1   (0)| 00:00:01 |
|* 10 | FILTER                            |                         |       |       |            |          |
|* 11 |   TABLE ACCESS BY INDEX ROWID      | XML_DROPBOX_PATH_IDX    |     1 | 3524 |     2   (0)| 00:00:01 |
|* 12 |    INDEX RANGE SCAN                | XML_DROPBOX_PATH_ID_IDX |     1 |       |     1   (0)| 00:00:01 |
|* 13 | FILTER                            |                         |       |       |            |          |
|* 14 |   TABLE ACCESS BY INDEX ROWID      | XML_DROPBOX_PATH_IDX    |     1 | 3524 |     2   (0)| 00:00:01 |
|* 15 |    INDEX RANGE SCAN                | XML_DROPBOX_PATH_ID_IDX |     1 |       |     1   (0)| 00:00:01 |
|* 16 | FILTER                            |                         |       |       |            |          |
|* 17 |   TABLE ACCESS BY INDEX ROWID      | XML_DROPBOX_PATH_IDX    |     1 | 3524 |     2   (0)| 00:00:01 |
|* 18 |    INDEX RANGE SCAN                | XML_DROPBOX_PATH_ID_IDX |     1 |       |     1   (0)| 00:00:01 |
|* 19 | FILTER                            |                         |       |       |            |          |
|* 20 |   TABLE ACCESS BY INDEX ROWID      | XML_DROPBOX_PATH_IDX    |     1 | 3524 |     2   (0)| 00:00:01 |
|* 21 |    INDEX RANGE SCAN                | XML_DROPBOX_PATH_ID_IDX |     1 |       |     1   (0)| 00:00:01 |
|* 22 | FILTER                            |                         |       |       |            |          |
|* 23 |   TABLE ACCESS BY INDEX ROWID      | XML_DROPBOX_PATH_IDX    |     1 | 3524 |     2   (0)| 00:00:01 |
|* 24 |    INDEX RANGE SCAN                | XML_DROPBOX_PATH_ID_IDX |     1 |       |     1   (0)| 00:00:01 |
|* 25 | FILTER                            |                         |       |       |            |          |
|* 26 |   TABLE ACCESS BY INDEX ROWID      | XML_DROPBOX_PATH_IDX    |     1 | 3524 |     2   (0)| 00:00:01 |
|* 27 |    INDEX RANGE SCAN                | XML_DROPBOX_PATH_ID_IDX |     1 |       |     1   (0)| 00:00:01 |
|* 28 | FILTER                            |                         |       |       |            |          |
|* 29 |   TABLE ACCESS BY INDEX ROWID      | XML_DROPBOX_PATH_IDX    |     1 | 3524 |     2   (0)| 00:00:01 |
|* 30 |    INDEX RANGE SCAN                | XML_DROPBOX_PATH_ID_IDX |     1 |       |     1   (0)| 00:00:01 |
|* 31 | FILTER                            |                         |       |       |            |          |
|* 32 |   TABLE ACCESS BY INDEX ROWID      | XML_DROPBOX_PATH_IDX    |     1 | 3524 |     2   (0)| 00:00:01 |
|* 33 |    INDEX RANGE SCAN                | XML_DROPBOX_PATH_ID_IDX |     1 |       |     1   (0)| 00:00:01 |
|* 34 | FILTER                            |                         |       |       |            |          |
|* 35 |   TABLE ACCESS BY INDEX ROWID      | XML_DROPBOX_PATH_IDX    |     1 | 3524 |     2   (0)| 00:00:01 |
|* 36 |    INDEX RANGE SCAN                | XML_DROPBOX_PATH_ID_IDX |     1 |       |     1   (0)| 00:00:01 |
|* 37 | FILTER                            |                         |       |       |            |          |
|* 38 |   TABLE ACCESS BY INDEX ROWID      | XML_DROPBOX_PATH_IDX    |     1 | 3524 |     2   (0)| 00:00:01 |
|* 39 |    INDEX RANGE SCAN                | XML_DROPBOX_PATH_ID_IDX |     1 |       |     1   (0)| 00:00:01 |
|* 40 | FILTER                            |                         |       |       |            |          |
|* 41 |   TABLE ACCESS BY INDEX ROWID      | XML_DROPBOX_PATH_IDX    |     1 | 3524 |     2   (0)| 00:00:01 |
|* 42 |    INDEX RANGE SCAN                | XML_DROPBOX_PATH_ID_IDX |     1 |       |     1   (0)| 00:00:01 |
|* 43 | FILTER                            |                         |       |       |            |          |
|* 44 |   TABLE ACCESS BY INDEX ROWID      | XML_DROPBOX_PATH_IDX    |     1 | 3524 |     2   (0)| 00:00:01 |
|* 45 |    INDEX RANGE SCAN                | XML_DROPBOX_PATH_ID_IDX |     1 |       |     1   (0)| 00:00:01 |
|* 46 | FILTER                            |                         |       |       |            |          |
|* 47 |   TABLE ACCESS BY INDEX ROWID      | XML_DROPBOX_PATH_IDX    |     1 | 3524 |     2   (0)| 00:00:01 |
|* 48 |    INDEX RANGE SCAN                | XML_DROPBOX_PATH_ID_IDX |     1 |       |     1   (0)| 00:00:01 |
|* 49 | FILTER                            |                         |       |       |            |          |
|* 50 |   TABLE ACCESS BY INDEX ROWID      | XML_DROPBOX_PATH_IDX    |     1 | 3524 |     2   (0)| 00:00:01 |
|* 51 |    INDEX RANGE SCAN                | XML_DROPBOX_PATH_ID_IDX |     1 |       |     1   (0)| 00:00:01 |
| 52 | NESTED LOOPS                      |                         |     1 | 10666 |     9   (0)| 00:00:01 |
| 53 |   NESTED LOOPS                     |                         |     1 | 10654 |     8   (0)| 00:00:01 |
| 54 |    NESTED LOOPS                    |                         |     1 | 9132 |     7   (0)| 00:00:01 |
| 55 |     NESTED LOOPS                   |                         |     1 | 7610 |     6   (0)| 00:00:01 |
| 56 |      NESTED LOOPS                  |                         |     1 | 6088 |     5   (0)| 00:00:01 |
| 57 |       NESTED LOOPS                 |                         |     1 | 4566 |     4   (0)| 00:00:01 |
| 58 |        NESTED LOOPS                |                         |     1 | 3044 |     3   (0)| 00:00:01 |
|* 59 |         TABLE ACCESS BY INDEX ROWID| XML_DROPBOX_PATH_IDX    |     1 | 1522 |     2   (0)| 00:00:01 |
|* 60 |          INDEX RANGE SCAN          | XML_DROPBOX_PATH_ID_IDX |     1 |       |     1   (0)| 00:00:01 |
|* 61 |         TABLE ACCESS BY INDEX ROWID| XML_DROPBOX_PATH_IDX    |     1 | 1522 |     1   (0)| 00:00:01 |
|* 62 |          INDEX RANGE SCAN          | XML_DROPBOX_PATH_ID_IDX |     1 |       |     0   (0)| 00:00:01 |
|* 63 |        TABLE ACCESS BY INDEX ROWID | XML_DROPBOX_PATH_IDX    |     1 | 1522 |     1   (0)| 00:00:01 |
|* 64 |         INDEX RANGE SCAN           | XML_DROPBOX_PATH_ID_IDX |     1 |       |     0   (0)| 00:00:01 |
|* 65 |       TABLE ACCESS BY INDEX ROWID | XML_DROPBOX_PATH_IDX    |     1 | 1522 |     1   (0)| 00:00:01 |
|* 66 |        INDEX RANGE SCAN            | XML_DROPBOX_PATH_ID_IDX |     1 |       |     0   (0)| 00:00:01 |
|* 67 |      TABLE ACCESS BY INDEX ROWID   | XML_DROPBOX_PATH_IDX    |     1 | 1522 |     1   (0)| 00:00:01 |
|* 68 |       INDEX RANGE SCAN             | XML_DROPBOX_PATH_ID_IDX |     1 |       |     0   (0)| 00:00:01 |
|* 69 |     TABLE ACCESS BY INDEX ROWID    | XML_DROPBOX_PATH_IDX    |     1 | 1522 |     1   (0)| 00:00:01 |
|* 70 |      INDEX RANGE SCAN              | XML_DROPBOX_PATH_ID_IDX |     1 |       |     0   (0)| 00:00:01 |
|* 71 |    TABLE ACCESS BY INDEX ROWID     | XML_DROPBOX_PATH_IDX    |     1 | 1522 |     1   (0)| 00:00:01 |
|* 72 |     INDEX RANGE SCAN               | XML_DROPBOX_PATH_ID_IDX |     1 |       |     0   (0)| 00:00:01 |
| 73 |   TABLE ACCESS BY USER ROWID       | XML_DROPBOX             |     1 |    12 |     1   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - filter(:B1<SYS_ORDERKEY_MAXCHILD(:B2))
   2 - filter("SYS_P6"."ORDER_KEY">:B1 AND "SYS_P6"."ORDER_KEY"<SYS_ORDERKEY_MAXCHILD(:B2) AND
              SYS_ORDERKEY_DEPTH("SYS_P6"."ORDER_KEY")=SYS_ORDERKEY_DEPTH(:B3)+1 AND
              SYS_XMLI_LOC_ISNODE("SYS_P6"."LOCATOR")=1)
   3 - access("SYS_P6"."PATHID"=HEXTORAW('6043') AND "SYS_P6"."RID"=:B1)
   4 - filter(:B1<SYS_ORDERKEY_MAXCHILD(:B2))
   5 - filter("SYS_P9"."ORDER_KEY">:B1 AND "SYS_P9"."ORDER_KEY"<SYS_ORDERKEY_MAXCHILD(:B2) AND
              SYS_ORDERKEY_DEPTH("SYS_P9"."ORDER_KEY")=SYS_ORDERKEY_DEPTH(:B3)+1 AND
              SYS_XMLI_LOC_ISNODE("SYS_P9"."LOCATOR")=1)
   6 - access("SYS_P9"."PATHID"=HEXTORAW('66A6') AND "SYS_P9"."RID"=:B1)
   7 - filter(:B1<SYS_ORDERKEY_MAXCHILD(:B2))
   8 - filter("SYS_P12"."ORDER_KEY">:B1 AND "SYS_P12"."ORDER_KEY"<SYS_ORDERKEY_MAXCHILD(:B2) AND
              SYS_ORDERKEY_DEPTH("SYS_P12"."ORDER_KEY")=SYS_ORDERKEY_DEPTH(:B3)+1 AND
              SYS_XMLI_LOC_ISNODE("SYS_P12"."LOCATOR")=1)
   9 - access("SYS_P12"."PATHID"=HEXTORAW('4203') AND "SYS_P12"."RID"=:B1)
10 - filter(:B1<SYS_ORDERKEY_MAXCHILD(:B2))
11 - filter("SYS_P15"."ORDER_KEY">:B1 AND "SYS_P15"."ORDER_KEY"<SYS_ORDERKEY_MAXCHILD(:B2) AND
              SYS_ORDERKEY_DEPTH("SYS_P15"."ORDER_KEY")=SYS_ORDERKEY_DEPTH(:B3)+1 AND
              SYS_XMLI_LOC_ISNODE("SYS_P15"."LOCATOR")=1)
12 - access("SYS_P15"."PATHID"=HEXTORAW('66BA') AND "SYS_P15"."RID"=:B1)
13 - filter(:B1<SYS_ORDERKEY_MAXCHILD(:B2))
14 - filter("SYS_P18"."ORDER_KEY">:B1 AND "SYS_P18"."ORDER_KEY"<SYS_ORDERKEY_MAXCHILD(:B2) AND
              SYS_ORDERKEY_DEPTH("SYS_P18"."ORDER_KEY")=SYS_ORDERKEY_DEPTH(:B3)+1 AND
              SYS_XMLI_LOC_ISNODE("SYS_P18"."LOCATOR")=1)
15 - access("SYS_P18"."PATHID"=HEXTORAW('550B') AND "SYS_P18"."RID"=:B1)
16 - filter(:B1<SYS_ORDERKEY_MAXCHILD(:B2))
17 - filter("SYS_P21"."ORDER_KEY">:B1 AND "SYS_P21"."ORDER_KEY"<SYS_ORDERKEY_MAXCHILD(:B2) AND
              SYS_ORDERKEY_DEPTH("SYS_P21"."ORDER_KEY")=SYS_ORDERKEY_DEPTH(:B3)+1 AND
              SYS_XMLI_LOC_ISNODE("SYS_P21"."LOCATOR")=1)
18 - access("SYS_P21"."PATHID"=HEXTORAW('652E') AND "SYS_P21"."RID"=:B1)
19 - filter(:B1<SYS_ORDERKEY_MAXCHILD(:B2))
20 - filter("SYS_P24"."ORDER_KEY">:B1 AND "SYS_P24"."ORDER_KEY"<SYS_ORDERKEY_MAXCHILD(:B2) AND
              SYS_ORDERKEY_DEPTH("SYS_P24"."ORDER_KEY")=SYS_ORDERKEY_DEPTH(:B3)+1 AND
              SYS_XMLI_LOC_ISNODE("SYS_P24"."LOCATOR")=1)
21 - access("SYS_P24"."PATHID"=HEXTORAW('44EC') AND "SYS_P24"."RID"=:B1)
22 - filter(:B1<SYS_ORDERKEY_MAXCHILD(:B2))
23 - filter("SYS_P31"."ORDER_KEY">:B1 AND "SYS_P31"."ORDER_KEY"<SYS_ORDERKEY_MAXCHILD(:B2) AND
              SYS_ORDERKEY_DEPTH("SYS_P31"."ORDER_KEY")=SYS_ORDERKEY_DEPTH(:B3)+1 AND
              SYS_XMLI_LOC_ISNODE("SYS_P31"."LOCATOR")=1)
24 - access("SYS_P31"."PATHID"=HEXTORAW('2C38') AND "SYS_P31"."RID"=:B1)
25 - filter(:B1<SYS_ORDERKEY_MAXCHILD(:B2))
26 - filter("SYS_P34"."ORDER_KEY">:B1 AND "SYS_P34"."ORDER_KEY"<SYS_ORDERKEY_MAXCHILD(:B2) AND
              SYS_ORDERKEY_DEPTH("SYS_P34"."ORDER_KEY")=SYS_ORDERKEY_DEPTH(:B3)+1 AND
              SYS_XMLI_LOC_ISNODE("SYS_P34"."LOCATOR")=1)
27 - access("SYS_P34"."PATHID"=HEXTORAW('3026') AND "SYS_P34"."RID"=:B1)
28 - filter(:B1<SYS_ORDERKEY_MAXCHILD(:B2))
29 - filter("SYS_P37"."ORDER_KEY">:B1 AND "SYS_P37"."ORDER_KEY"<SYS_ORDERKEY_MAXCHILD(:B2) AND
              SYS_ORDERKEY_DEPTH("SYS_P37"."ORDER_KEY")=SYS_ORDERKEY_DEPTH(:B3)+2 AND
              SYS_XMLI_LOC_ISNODE("SYS_P37"."LOCATOR")=1)
30 - access("SYS_P37"."PATHID"=HEXTORAW('4F1A') AND "SYS_P37"."RID"=:B1)
31 - filter(:B1<SYS_ORDERKEY_MAXCHILD(:B2))
32 - filter("SYS_P40"."ORDER_KEY">:B1 AND "SYS_P40"."ORDER_KEY"<SYS_ORDERKEY_MAXCHILD(:B2) AND
              SYS_ORDERKEY_DEPTH("SYS_P40"."ORDER_KEY")=SYS_ORDERKEY_DEPTH(:B3)+2 AND
              SYS_XMLI_LOC_ISNODE("SYS_P40"."LOCATOR")=1)
33 - access("SYS_P40"."PATHID"=HEXTORAW('7E65') AND "SYS_P40"."RID"=:B1)
34 - filter(:B1<SYS_ORDERKEY_MAXCHILD(:B2))
35 - filter("SYS_P43"."ORDER_KEY">:B1 AND "SYS_P43"."ORDER_KEY"<SYS_ORDERKEY_MAXCHILD(:B2) AND
              SYS_ORDERKEY_DEPTH("SYS_P43"."ORDER_KEY")=SYS_ORDERKEY_DEPTH(:B3)+1 AND
              SYS_XMLI_LOC_ISNODE("SYS_P43"."LOCATOR")=1)
36 - access("SYS_P43"."PATHID"=HEXTORAW('7497') AND "SYS_P43"."RID"=:B1)
37 - filter(:B1<SYS_ORDERKEY_MAXCHILD(:B2))
38 - filter("SYS_P46"."ORDER_KEY">:B1 AND "SYS_P46"."ORDER_KEY"<SYS_ORDERKEY_MAXCHILD(:B2) AND
              SYS_ORDERKEY_DEPTH("SYS_P46"."ORDER_KEY")=SYS_ORDERKEY_DEPTH(:B3)+1 AND
              SYS_XMLI_LOC_ISNODE("SYS_P46"."LOCATOR")=1)
39 - access("SYS_P46"."PATHID"=HEXTORAW('2D8D') AND "SYS_P46"."RID"=:B1)
40 - filter(:B1<SYS_ORDERKEY_MAXCHILD(:B2))
41 - filter("SYS_P49"."ORDER_KEY">:B1 AND "SYS_P49"."ORDER_KEY"<SYS_ORDERKEY_MAXCHILD(:B2) AND
              SYS_ORDERKEY_DEPTH("SYS_P49"."ORDER_KEY")=SYS_ORDERKEY_DEPTH(:B3)+1 AND
              SYS_XMLI_LOC_ISNODE("SYS_P49"."LOCATOR")=1)
42 - access("SYS_P49"."PATHID"=HEXTORAW('4486') AND "SYS_P49"."RID"=:B1)
43 - filter(:B1<SYS_ORDERKEY_MAXCHILD(:B2))
44 - filter("SYS_P66"."ORDER_KEY">:B1 AND "SYS_P66"."ORDER_KEY"<SYS_ORDERKEY_MAXCHILD(:B2) AND
              SYS_ORDERKEY_DEPTH("SYS_P66"."ORDER_KEY")=SYS_ORDERKEY_DEPTH(:B3)+1 AND
              SYS_XMLI_LOC_ISNODE("SYS_P66"."LOCATOR")=1)
45 - access("SYS_P66"."PATHID"=HEXTORAW('5005') AND "SYS_P66"."RID"=:B1)
46 - filter(:B1<SYS_ORDERKEY_MAXCHILD(:B2))
47 - filter("SYS_P69"."ORDER_KEY">:B1 AND "SYS_P69"."ORDER_KEY"<SYS_ORDERKEY_MAXCHILD(:B2) AND
              SYS_ORDERKEY_DEPTH("SYS_P69"."ORDER_KEY")=SYS_ORDERKEY_DEPTH(:B3)+1 AND
              SYS_XMLI_LOC_ISNODE("SYS_P69"."LOCATOR")=1)
48 - access("SYS_P69"."PATHID"=HEXTORAW('3935') AND "SYS_P69"."RID"=:B1)
49 - filter(:B1<SYS_ORDERKEY_MAXCHILD(:B2))
50 - filter("SYS_P59"."ORDER_KEY">:B1 AND "SYS_P59"."ORDER_KEY"<SYS_ORDERKEY_MAXCHILD(:B2) AND
              SYS_ORDERKEY_DEPTH("SYS_P59"."ORDER_KEY")=SYS_ORDERKEY_DEPTH(:B3)+1 AND
              SYS_XMLI_LOC_ISNODE("SYS_P59"."LOCATOR")=1)
51 - access("SYS_P59"."PATHID"=HEXTORAW('37CE') AND "SYS_P59"."RID"=:B1)
59 - filter(SYS_XMLI_LOC_ISNODE("SYS_P49"."LOCATOR")=1)
60 - access("SYS_P49"."PATHID"=HEXTORAW('4486') )
61 - filter(SYS_XMLI_LOC_ISNODE("SYS_P62"."LOCATOR")=1 AND
              "SYS_P49"."ORDER_KEY"<"SYS_P62"."ORDER_KEY" AND "SYS_P62"."ORDER_KEY"<SYS_ORDERKEY_MAXCHILD("SYS_P49".
              "ORDER_KEY") AND SYS_ORDERKEY_DEPTH("SYS_P49"."ORDER_KEY")+1=SYS_ORDERKEY_DEPTH("SYS_P62"."ORDER_KEY")
62 - access("SYS_P62"."PATHID"=HEXTORAW('780B') AND "SYS_P62"."RID"="SYS_P49"."RID")
63 - filter(SYS_XMLI_LOC_ISNODE("SYS_P27"."LOCATOR")=1 AND
              "SYS_P27"."ORDER_KEY"<"SYS_P49"."ORDER_KEY" AND "SYS_P49"."ORDER_KEY"<SYS_ORDERKEY_MAXCHILD("SYS_P27".
              "ORDER_KEY") AND SYS_ORDERKEY_DEPTH("SYS_P27"."ORDER_KEY")+1=SYS_ORDERKEY_DEPTH("SYS_P49"."ORDER_KEY")
64 - access("SYS_P27"."PATHID"=HEXTORAW('49C4') AND "SYS_P49"."RID"="SYS_P27"."RID")
65 - filter(SYS_XMLI_LOC_ISNODE("SYS_P46"."LOCATOR")=1 AND
              "SYS_P27"."ORDER_KEY"<"SYS_P46"."ORDER_KEY" AND "SYS_P46"."ORDER_KEY"<SYS_ORDERKEY_MAXCHILD("SYS_P27".
              "ORDER_KEY") AND SYS_ORDERKEY_DEPTH("SYS_P27"."ORDER_KEY")+1=SYS_ORDERKEY_DEPTH("SYS_P46"."ORDER_KEY")
66 - access("SYS_P46"."PATHID"=HEXTORAW('2D8D') AND "SYS_P46"."RID"="SYS_P27"."RID")
67 - filter(SYS_XMLI_LOC_ISNODE("SYS_P52"."LOCATOR")=1 AND
              "SYS_P46"."ORDER_KEY"<"SYS_P52"."ORDER_KEY" AND "SYS_P52"."ORDER_KEY"<SYS_ORDERKEY_MAXCHILD("SYS_P46".
              "ORDER_KEY") AND SYS_ORDERKEY_DEPTH("SYS_P46"."ORDER_KEY")+1=SYS_ORDERKEY_DEPTH("SYS_P52"."ORDER_KEY")
68 - access("SYS_P52"."PATHID"=HEXTORAW('6AFA') AND "SYS_P52"."RID"="SYS_P46"."RID")
69 - filter(SYS_XMLI_LOC_ISNODE("SYS_P24"."LOCATOR")=1 AND
              "SYS_P24"."ORDER_KEY"<"SYS_P27"."ORDER_KEY" AND "SYS_P27"."ORDER_KEY"<SYS_ORDERKEY_MAXCHILD("SYS_P24".
              "ORDER_KEY") AND SYS_ORDERKEY_DEPTH("SYS_P24"."ORDER_KEY")+1=SYS_ORDERKEY_DEPTH("SYS_P27"."ORDER_KEY")
70 - access("SYS_P24"."PATHID"=HEXTORAW('44EC') AND "SYS_P27"."RID"="SYS_P24"."RID")
71 - filter(SYS_XMLI_LOC_ISNODE("SYS_P4"."LOCATOR")=1 AND
              "SYS_P4"."ORDER_KEY"<"SYS_P24"."ORDER_KEY" AND "SYS_P24"."ORDER_KEY"<SYS_ORDERKEY_MAXCHILD("SYS_P4"."O
              RDER_KEY") AND SYS_ORDERKEY_DEPTH("SYS_P4"."ORDER_KEY")+1=SYS_ORDERKEY_DEPTH("SYS_P24"."ORDER_KEY"))
72 - access("SYS_P4"."PATHID"=HEXTORAW('5B3D') AND "SYS_P24"."RID"="SYS_P4"."RID")
Note
   - dynamic sampling used for this statement (level=2)

DM3.0 EA2: Logical Model Relation Cardinality:Source Optional mislabeled?

In logical model, created a 1:N non-identifying relation between 2 entities - Parent and Child. Parent is 1:N with Child. Both entities have a single column primary key - parent_id and child_id respectively. I would like to enforce RI such that a parent may exist with no children, but a child may not exist without a parent.
In the logical model the relation properties, cardinality - I modify the Source Optional and Target Optional checkboxes to achieve my desired result. I first tried checking Target Optional and leaving Source Optional un-checked. I then engineer a physical model and generate DDL for Oracle 11g I get this constraint:
SQL>ALTER TABLE child
2      ADD CONSTRAINT Relation_1 FOREIGN KEY
3      (
4       parent_id
5      )
6      REFERENCES parent
7      (
8       parent_id
9      )
10      ON DELETE SET NULL
11 ;
Table altered.Here's a test case illustrating this isn't quite what I wanted (starting with both tables empty):
SQL>
SQL>
SQL>insert into parent (parent_id) values (1);
1 row created.
SQL>commit;
Commit complete.
SQL>
SQL>insert into child (child_id, parent_id) values (901, 1);
1 row created.
SQL>commit;
Commit complete.
SQL>
SQL>delete from parent;
delete from parent
ERROR at line 1:
ORA-01407: cannot update ("ODS_ETL_OWNER"."CHILD"."PARENT_ID") to NULLIf I have Source Optional checked, and Target Optional not checked, engineer a physical model and generate DDL for Oracle 11g I get this constraint which produces the desired results with my test case:
SQL>ALTER TABLE child
2      ADD CONSTRAINT Relation_1 FOREIGN KEY
3      (
4       parent_id
5      )
6      REFERENCES parent
7      (
8       parent_id
9      )
10 ;
Table altered.
SQL>
SQL>insert into parent (parent_id) values (1);
1 row created.
SQL>commit;
Commit complete.
SQL>
SQL>insert into child (child_id, parent_id) values (901, 1);
1 row created.
SQL>commit;
Commit complete.
SQL>
SQL>delete from parent;
delete from parent
ERROR at line 1:
ORA-02292: integrity constraint (ODS_ETL_OWNER.RELATION_1) violated - child
record foundBut that seems backwards - and the documentation also reads as if it’s backwards. Am I missing something or are the Source Optional and Target Optional checkboxes mislabeled? Should they be Source Manditory and Target Manditory?

I would like to enforce RI such that a parent may exist with no children, but a child may not exist without a parent.You need to set parent as optional and child to be mandatory.
Am I missing something or are the Source Optional and Target Optional checkboxes mislabeled? Should they be Source Manditory and Target Manditory?There is a relationship and two ends of that relationship and you can set for each end whether it's optional or not. And that's seen directly using Barker notations. Source and target optionality place will be swapped on diagram if you use IE notation.
I expected that cardinality part could be more confusing for you because at source end you define cardinality of the target, but it seems you have no problem with that.
Philip

Regarding problem in cardinality for context in alv display

Hello,
I have a problem with caridianalty with context when displaying in alv. If the cardinality is 1..N then its displaying the data in alv. But if cardinality is changed to 0..N then its giving a cardinality error.
what i want to do is if the internal table is empty i should refresh the alv with the no records for the second time. so please let me know if there is any method to bind the alv with empty internal table.
Regards
Anil Kumar K

Hi Anil.....
Hope So Following Link will help-ful for u regarding Model-Binding and Data Binding....
1.http://help.sap.com/saphelp_erp2005/helpdata/en/89/5d3d4d4d28c84eb01c635d95a93e0f/frameset.htm
2.http://help.sap.com/saphelp_erp2005/helpdata/en/8f/db0c533a4e514d9720ed2307a40f84/frameset.htm
3.http://help.sap.com/saphelp_erp2005/helpdata/en/fb/fbb84c20df274aa52a0b0833769057/frameset.htm
Best Regard's
Dheerendra

How to edit values in a node of cardinality 0...n at runtime.

Hi experts,
I am trying to reset value of an attribute of a node of cardinality 0...n at runtime. I am getting data in this node from a BAPI. I want to set one column's value to zero on display in the table created from this node. Please suggest what to do.
Thanks & Regards.
Vaibhav Tiwari.

Try something like this:
    DATA lo_nd_sflight TYPE REF TO if_wd_context_node.
    DATA lt_sflight TYPE wd_this->elements_sflight.
    FIELD-SYMBOLS: <fs_sflight> TYPE wd_this->element_sflight.
'*   navigate from <CONTEXT> to <SFLIGHT> via lead selection
    lo_nd_sflight = wd_context->get_child_node( name = wd_this->wdctx_sflight ).
'*   get all declared attributes
    lo_nd_sflight->get_static_attributes_table(
      IMPORTING
        table = lt_sflight ).
    LOOP AT lt_sflight ASSIGNING <fs_sflight>.
'*     Here do something like <fs_sflight>-fldate = syst-datum.
    ENDLOOP.
    lo_nd_sflight->bind_table( lt_sflight ).

Relation Properties - Cardinality - "Identifying" vs. "Target Optional"

Version 3.0.0 build 653
Using the logical design, within the "Relation Properties" > "Cardinality" dialog,
the "Identifying" and "Target Optional" checkboxes are mutually exclusive.
Can somebody explain that to me?
The help defines "Identifying" as:
"Controls whether this is an identifying relationship. When there is an identifying relationship between a parent entity and a child entity, when the relational model is generated, the following occurs in the child table: *the foreign key to the parent becomes part of the primary key of the child.* (In non-identifying relationships, the foreign key to the parent table is just another column in the child table and is not part of the primary key.)"
and "Target Optional" as:
"Controls whether the *target entity in the relation must contain one or more instances*. If this option is enabled, there can be zero target instances; if this option is disabled, one or more target instances are required."
Just because a target entity's PK includes the source entity's PK,
why would that require an instance of the target entity to exist?
I'm trying to model a parent/child relationship where an instance of the child entity can't exist without the parent instance (no orphans) but that shouldn't make an instance of the child entity required.
I'm far from a data modeling guru so thanks in advance to whomever can explain what I'm missing.

Hi Jeff,
relationship has two ends - if one end is optional that means it can exists on its own (related foreign key columns will allow nulls); if it's mandatory then it can exist only in the context of other end (entity) of relationship.
"Identifying" goes little bit further - FK columns become part of primary key which implies not null columns.
Just because a target entity's PK includes the source entity's PK,
why would that require an instance of the target entity to exist?it doesn't require instance of source entity to exists, however foreign key constraint is created and it requires existence of related instance of source entity.
I'm trying to model a parent/child relationship where an instance of the child entity can't exist without the parent instance (no orphans) you just need to set related child entity as mandatory, no need to use identifying for that. Foreign key will be created for defined relationship when you engineer to relational model and delete rule will be set:
- "no action/restrict" if parent entity is optional;
- "cascade" if parent entity is mandatory;
Philip

Unable to add value to model node with cardinality 0..n

Hi All,
Im working with Webdynpro Java.i have an issue here.i have a input field item named customer and a drop down box item location.when i give customer and location as inputs,a WSDL (named Equipment WSDL) is called.the result is a drop down list containing equipments id
i took a custom node location with cardinaliy 0..n.i gave static values as input for location.i need to set the location values to model node location.when i m giving a single value to custom node location,that static value is not accepted by model node location(in WSDL) whose cardinality is 0..n.
Please suugest a solution for this issue
With Regards,
Ushasri.

HI Ushashri,
What do you mean by 'static value is not accepted by model node location'
how you have done the mapping
send me the hierarchy of rfc and ur value node
With Regards
Naidu

How to set the cardinality property as 1..n for a dynamically created node

Hi...everybody
    I am creating Dropdown by index UI element and the
context atrributes dynamically.To bind multiple data to a dropdown
the cardinality property of the node should be 0..n or 1..n,
But i could not set the property of the dynamically created context node to 0..n ...
can any body suggest me..
I implemented the following code in WDDoModify View
IWDTransparentContainer tc=(IWDTransparentContainer)view.getElement("RootUIElementContainer");
IWDNodeInfo node = wdContext.getNodeInfo().addChild("DynamicNode",null,true,true,false,false,false,true,null,
          null,null);
IWDAttributeInfo strinfo=node.addAttribute("Value","ddic:com.sap.dictionary.string");
dbyindex.bindTexts(strinfo);
tc.addChild(dbyindex);
I could successfully display one value in the drop down,by adding the following code before the line tc.addchild(dbyindex);
IWDNode node1=wdContext.getChildNode("DynamicNode",0);
IWDNodeElement nodeElement=node1.createElement();
nodeElement.setAttributeValue("Value","Hello");
node1.addElement(nodeElement);
but when
i am trying to bind multiple values i am getting Exception ,,,,

hi
you are getting the exception because of cardinality property.
i.e   true,false and
you are trying to add morethan one element.
so,if you want to add morethan one than one element you have to set the cardinality property to true,true (or) false,true.
In your code do the following modification for changing the cardinality.
For 0..n -->false,true
      1..n-->true,true
IWDTransparentContainer tc=(IWDTransparentContainer)view.getElement("RootUIElementContainer");
IWDNodeInfo node = wdContext.getNodeInfo().addChild("DynamicNode",null,true,true,false,false,false,true,null,
null,null);
IWDAttributeInfo strinfo=node.addAttribute("Value","ddic:com.sap.dictionary.string");
dbyindex.bindTexts(strinfo);
tc.addChild(dbyindex);
hope this will solve your problem.
In addchild(..) the parameters are
addChild("Name ,
                Element class for model node ,
                Is singleton? ,
                Cardinality ,
                Selection cardinality ,
                Initialise lead selection? ,
                Datatype ,
                Supplier function ,
                 Disposer function);
Regards
sowmya

How to set value to Model Node of cardinality 0..N

hi
I am looking for a way to set value to a model node of cardinality 0..N
i imported a WSDL into my applicaion , which has the following Node Structure.
Context
--- ModelNode_Request
      ---ModelNode2_Input
      ---ModleNode3_Roles [ cardinality 0..n singleton 1..1]
           ****Model_Attribute RoleID     <<<<<<<<<<<<
           ****Model_Attribute SysID      <<<<<<<<<<<<
---ModelNode_Response
i tried with the below code but effort went in vain.
i tried following ways to set the value but , i get Nullpointer expection error.
     wdContext.nodeRequest__SubmitRequest().nodeRequestDetails().nodeRoles().
          currentRolesElement().setRoleId("BASIC");
     wdContext.nodeRequest__SubmitRequest().nodeRequestDetails().nodeRoles().
          currentRolesElement().setSysId("R3_220");
i aslo looked into the forum https://www.sdn.sap.com/irj/scn/thread?messageID=2035342 but couldnt find any solid solution.
It would be great if some one can throw some snippets on the same.
Thanks
Edited by: RR on Dec 22, 2008 5:48 PM

Hi RR,
As far as i know u can set model nodes and values nodes are different. whats shown in the link is for values node. u should do differently for model node..
    Since this is a model node...u first need to create an object of the node type. then create an arraylist for that and then add values..
try this..
// Create an object for structures in the node to be used
Yweb_Po_Items objPOItems = null; // where Yweb_Po_Items is the structure of the node...
// Create an abstractlist for structures in the RFC node to be used, if u are planning to give single or multiple rows (in node/table) as input to the RFC
AbstractList POObjAbsList = new Yweb_Po_Items.Yweb_Po_Items_List();
objPOItems = new Yweb_Po_Items();
//    /set first set of values
objPOItems.setColumn1(u201Cabcu201D); // here hard codede for example
objPOItems.setColumn2(u201Cabcfghu201D);
// add the object to the abstract list
POObjAbsList.add(objPOItems);
//    /set second set of values
objPOItems.setColumn1(u201Cnewabcu201D);
objPOItems.setColumn2(u201Cnewabcfghu201D);
// add the object to the abstract list again
POObjAbsList.add(objPOItems); // now u got 2 records
// now set the abstractlist to the node in the RFC
objGoodsReceiptPO.setPo_Items_In(POObjAbsList);
Hope this information is useful...
Thanks
Md. Yusuf

Hardcode values of the node with cardinality 0..n

Good day!
I need to hardcode a list of element to the node with cardinality 0..n.
Node has two attributes.
How can I fill the node with a few element in the input mapping? I know I can do it with a single element by separating values by comma. Is it possible to fill the node?

Hello.
I've the same problem. Can you say how to set list of values for a structure?
For example, we've node FIELD containing two attributes: ID and NAME.
FIELD is a node with cardinality 0..*. How to set at least two elements to the node?
Your example works only for simple attributes with cardinality 0..*, but it doesn't work for structures.
Best Regards,
Timur Semenchuk.

Cardinality

Similar Messages

Maybe you are looking for