Custom attachment entity using DocuRefEntity as root — GET returns empty, POST returns RecId 0

(1) Share

Report

Posted on by Raed Bzour

127

Hi everyone,

I am building a custom OData data entity to expose document attachments for a custom table called MPWorkerTransHeader (from a custom module), similar to how CustomerAttachmentsV2Entity works for CustTable.

My entity setup:
- Root datasource: DocuRefEntity
- Joined datasource: MPWorkerTransHeader (IsReadOnly: Yes)

-MPWorkerTransHeader joined with HcmWorker
- Relations on MPWorkerTransHeader:
- DocuRefEntity.RefRecId == MPWorkerTransHeader.RecId
- DocuRefEntity.RefTableId == MPWorkerTransHeader.TableId
- DocuRefEntity.RefCompanyId == MPWorkerTransHeader.DataAreaId
- No ranges defined
- IsPublic: Yes
- Entity class only has postLoad() to populate FileContents virtual field

The problem:
1. GET returns empty even when I manually insert a DocuRef record via SQL with the correct RefTableId and RefRecId pointing to MPWorkerTransHeader
2. POST returns: "Write returned RecId 0 for table row of type 'MPWorkerTransDocumentAttachmentEntity'"

I noticed that DocuRefEntity has:
- IsPublic: No
- Tags: Internal use only

My questions:
1. Is DocuRefEntity meant to be used as a root datasource for custom entities, or is it truly internal only?
2. Why would GET return empty even when the DocuRef record exists in SQL with the correct RefTableId?
3. For POST, why does Write return RecId 0 when DocuRefEntity is the root datasource?
4. Should I use DocuRef table directly as root instead of DocuRefEntity?

Any guidance is appreciated. Thank you

Categories:

Dynamics 365 Finance

I have the same question (0)

All responses (4)

Answers (0)

Sort by

Raed Bzour 127 on at

Like (0)

Report
Copy link

Link copied!

Was this reply helpful? Yes No
Martin Dráb 239,253 Most Valuable Professional on at

Like (1)

Report
Copy link

Link copied!

You need to do more work on the problem isolation. For example, maybe you data entity never returns any data and therefore testing the OData service isn't worth the effort, because it can't work either. Or maybe you'll find that the entity is correct and you indeed has a problem with OData only, e.g. because you query a wrong company.

I would begin with opening SSRS and querying the underlying view there. If it doesn't return any data, I'd then open the view defining and analyze the query, e.g. whether all join conditions are correct. There you can also play with the query, e.g. checking if you start getting data if you remove a joined table.

Was this reply helpful? Yes No
Raed Bzour 127 on at

Like (0)

Report
Copy link

Link copied!

Hi Martin Dráb,

Thank you for your guidance — it helped a lot.

I solved the GET method by:
1. Changing the root datasource from DocuRefEntity to DocuRef directly
2. Using cross-company=true in the OData request

The GET now returns data correctly.

However, POST still returns:
{
"value": "Write returned RecId 0 for table row of type 'MPWorkerTransDocumentAttachmentEntity'."
}

My current setup:
- Root datasource: DocuRef (IsReadOnly: No)
- DocuValue joined via OuterJoin (IsReadOnly: No)
- MPWorkerTransHeader joined via InnerJoin (IsReadOnly: Yes)
- mapEntityToDataSource() sets RefTableId, RefRecId, RefCompanyId, ActualCompanyId on DocuRef
- postInsert() creates DocuValue and links ValueRecId back to DocuRef

RecId 0 means the insert is not saving but no error is thrown. Could you advise what might cause a silent RecId 0 on POST for a data entity?

Thank you

Was this reply helpful? Yes No
Martin Dráb 239,253 Most Valuable Professional on at

Like (0)

Report
Copy link

Link copied!

What did you find when you debugged your code? You somehow forgot to mentioned that, such as whether your postInsert() method does its job or not. By the way, I'm not aware of any postInsert() method of data entities, therefore it sounds like your own method that you call from a place that you forgot to mention, or you don't call it all.

Anyway, the idea of not to use DocuRefEntity and rather reimplement all its logic inside your entity doesn't sound wise to me. Why did you decide to do so? And if you really insist on it, make sure that you actually copy the logic, because you're currently missing a lot of it.

Was this reply helpful? Yes No