The attachment functionality via personalization has got two limitations. The first limitation has a workaround and second limitation has some proper solution. What are these limitations and how can we overcome those? We will discuss those in this article. The first limitation is that you can specify only one primary key when defining attachments via personalization. For example if you wish to capture attachments against a combination of PO Header Id and PO Line Number, then in such a case you will not be able to implement this requirement via personalization. It must be noted that this is just an example, because in real life you would rather use po_line_id as the primary key. But in some project cases we do need composite primary key to identify the attachments. The second limitation is that the view object attribute that is used as a primary key of attachment must have a value populated in it, otherwise you cannot upload the attachments. It sounds obvious that you need a primary key value to attach documents against it. This is logical because you must have the transaction_id in place before you can load attachments against that transaction. However in reality, most of the screens generate the primary key just prior to the commit taking place, which means attachments can not be uploaded until after the save/apply button has been clicked by the user.
In this article we will discuss the possible solutions for both these limitations
Add Comment (6)
