Hi Gaurav,
the value of OData services is, that the structure of the services can be chosen indepedently from the structure in the backend, exactly as required by the client application. Particularly, you are free to break up results of one function module into several entity types, if appropriate.
If the export parameters of the function module are individual fields as well as a table, you will _have_to_ model separate entity types: one for the "main" entity type consisiting of the individual fields, and another one for the "dependent" entity type which reflects the structure of one line of the table.
Then you can add an association between the main entity type and the dependent entity type. After that, you can add a navigation property from the main entity type to the dependent entity type. Thus, if your client requests one main entity, the result will include a link to the set of dependent entities, and the client can follow that link to receive all the entities which correspond to the table entries of the function module.
This structure is necessary, because OData services follow the REST webservice paradigm. REST makes the development of client applications much easier, but one condition for that is, that there are no table attributes in entity types. There are entities as flat structures, and there are sets of entities. If there is an entity which is linked to several datasets with the same structure, then this situation has to be modeled as separate entity types with a 1:m relationship.
Best regards,
Ringo