Prodataset rejected flag

I'm not aware of any difference in how REJECTED and ERROR are treated in the ProDataSet merge. (I would check the documentation.)

If think this flag provides a level of granularity that might be useful if you use ProDataSets as the transport medium in a Service Provider implementation. It can enable you to distingusih between an actual error on the record or a rollback due to an error elsewhere.

An example:

The ADM2 has been enabled to act as a Service Requester in an OERA compliant architecture. This integration uses the ProDataSet's row level error and rejected flags to communicate details of a failed submit.

An SDO based application enforces a transaction for all data that are submitted together, but in the SOA support we leave the transaction resolution to the service. We allow the service to use the REJECTED flag to identify a record that was rolled back while the ERROR flag identifies records that actually caused an error. (No flag does of course mean that the record was submitted sucessfully.)

This is not essential information. We certainly need a record level error flag, but it would all work with ERROR flags, but the ADM2 has some optional error handling features that benefits from this.

We allow the user to have different rollback behavior of deletes, depending on this flag. An ERROR delete can be undone, so it is visible for inspection, while you can keep the REJECTED deletes deleted, so that they can be resubmitted when the ERRORs are fixed.

Whether this is a good UI or not is up to the developer to decide. This is optional behavior and just mentioned as an example, but I'm sure there are other and more important cases where a rich client might give better user feedback if it knows whether a record was rolled back due to other mistakes or its own.

The shrink wrap was off the docs and the help but I couldn't find anything specific to my question. Also I was specifically referring to the :error flag and then undo. I haven't got a copy of autoedge handy here but from memory the transaction was started in one on the services, so I'm not sure how the gateway controls other than perhaps indicating if 1 transaction or not. When I first saw the code I assume that the error or rejected flag controlled it, but soon found it didn't and added the undo myself. While it's scoped to on error undo all the operations had no-error set.

How is the undo controlled?

Miles

REJECTED is an optional flag that allows you to add a bit more granularity to the error handling. It can be used as such also on a ProDataSet, if needed.

When set at record level it will behave as ERROR and cause an undo of the changes when you merge the change dataset with the original. I assume this is how it is done in the original OERI (on the client side, but as part of the service).

A standard data service need to be able to do a complete rollback as it cannot assume that all consumers are prepared to do their own rollback. This means that all new records will be gone and all deletes will be undone. Changes that caused optimistic locking conflicts will (probably) be overwritten.

A rich client might want to allow the user to interfere and decide whether to cancel all or some or just fix some errors and resubmit. The ADM2 want the service response to leave all error flags intact for this reason. In addition to allowing the user to interfere it also has optional features for variations of lock conflict resolution and variations of undo of deletes.

The ideal data service should probably provide one (batch) interface that just returns data merged, and one (rich gui) interface that just returns the submitted changes with server errors intact. The first variation would probably also extract the changes from the original dataset while the second might just accept a change dataset. The first interface could just be built on top of the second. (Or the second can be added underneath the first...)

I don't think any of our samples shows how to control transactions and how to use the REJECTED flag on the server side in this context. Adding generic support of transaction scope might be challenging, while controlling this manually in each entity or dao probably is much easier.

A service that does provide granularity with REJECTED will typically not depend on the client being able to handle this, since it behaves as ERROR in the default ProDataSet merge. (It will need to be documented though to prevent some implementer from using the ERROR flag exclusively)

I tested the effect of setting error, rejected, and error-string on the buffer and the dataset on a server procedure. By themselves they had not apparent effect. To achieve the desired effect I checked the dataset error flag (which I had set) and on dataset:error did an undo. This seemed the only reliable way ensure the current and prior transactions are undo.

In daSupport they seem to partly achieve this by NOT having a no-error on save-row-changes, but from memory this caused error messages in the appserver log.

The REJECTED and ERROR flags on buffer rows has an effect when you merge a change dataset with these flags (set on server) with the original dataset (on client) using MERGE-CHANGES.

The change dataset must have been extracted from the client dataset using the GET-CHANGES method on the buffer or dataset. This extracts all records with changes from the original dataset. You typically pass this to the server where the flags will be set on error and then use MERGE-CHANGES to complete the submit/save operation in the original dataset. The original dataset will have no before image records after this operation. The records with ERROR or REJECTED will have been rolled back while other changes will have been accepted.

The ERROR-STRING has no default behavior and require parsing of the records in the change dataset. In a rich gui client you would parse the returned records in any case, as the MERGE-CHANGES is to course-grained. You would use the error flags to figure out what to do.

Non-transactional rich GUI client record level merging of before and after records with potential errors is challenging, but the ABL provides a rich set of support methods for this. You'd probably also throw in some old ABL methods like buffer-copy to achieve the desired effect. adm2/dataview.p processSubmitExceptions can give you an idea of what might be required. Don't use it as a basis for your own though, it is overkill for the vast majority of cases and depend on other operations before this. (Warning: the code is not fully optimized, there might be more efficient/elegant ways to achieve the same result)

--

A real data access implementation would most certainly use NO-ERROR on the SAVE-ROW-CHANGES and deal with ERROR and ERROR-STRING manually. Not only to suppress error messages, but also to capture ABL error messages or trigger return-values.

The effect on the merge is useful information, but my concern is on the commit to the data base and transactions scooping.

I have had personal experience with auto-edge being used as a basis for a production system and there has been discussion on the peg where it appears that others are using auto-edge as well. In addition to having worked in an environment where auto-edge was used in production, I developed a framework from code examples presented by John Sadd.

The thing is that these are examples and not full featured and testing code that can be used in a production environment. In addition to the this when you start using a new framework, you are not fully aware how things work or were designed to work. So I found that because of lack of understanding and having been fully tested, things didn't work as they should.

For example adding no-error to save-row-changes may be ok where there is a single transaction, but where there are prior successful saves in a "commit as single transaction" mode earlier transactions are not undone. Hence my interest in the error and rejected attributes. The only way that I found was to check the attributes and undo changes.

From your answers to date it seems that there is no effect on the server-side of setting error, rejected, or error-string, other than through you code or the code of the framework.

Also from my experience it would seem appropriate that when an example frame work is installed in a production environment there aught be a warning that the framework is not a full featured and tested production framework. If would seem that appropriate training, review of the features, and testing should also be provided and encouraged/required.

Miles

I have had personal experience with auto-edge being

used as a basis for a production system and there has

been discussion on the peg where it appears that

others are using auto-edge as well. In addition to

having worked in an environment where auto-edge was

used in production, I developed a framework from code

examples presented by John Sadd.

The thing is that these are examples and not full

featured and testing code that can be used in a

production environment. In addition to the this when

you start using a new framework, you are not fully

aware how things work or were designed to work. So I

found that because of lack of understanding and

having been fully tested, things didn't work as they

should.

I think if you read the supporting documents and the welcome postings etc for both Johns original work, and AutoEdge, you will see that both do state the goal of the material. For example:

"The intention is that you will refer to and study the material and learn from them, gain a better understanding of how to think about the problems the architecture is intended to help you solve, and decide how best to adapt the material to your own specific requirements."

and from the AutoEdge Welcome page "AutoEdge is not a complete application nor are all OpenEdge capabilities included. ...But, please understand, you need to assess your particular situation and develop your own conclusions/designs because outside of the context of this application architecture or these specific business requirements, something may not make as much sense."

We encouraged people to learn from the materials and then apply what they've learnt, it is not expected that the materials are taken as-is and put into a production environment. I'm sure you'll find many messages on the forums discussing this very topic, and the 'industrial strength' of the examples posted.

Mike

I think if you read the supporting documents and the

welcome postings etc for both Johns original work,

and AutoEdge, you will see that both do state the

goal of the material. For example:

"The intention is that you will refer to and study

the material and learn from them, gain a better

understanding of how to think about the problems the

architecture is intended to help you solve, and

decide how best to adapt the material to your own

specific requirements."

I think you miss the point Miles makes: the proposed approach turns out hard to implement in real life applications due to ABL "features". We have had the same experience with the ProDataSet (see our beta-feedback in the past). Some combinations simply don't work. New flags have been introduced to cover things, but that makes the language harder to understand. A simple example: in the very beginning of the ProDataSet the error string was part of the transaction. So when you set the error flag and rolled back the transaction, the error would be undone and you couldn't display it in the UI-tier. These simple things makes you question how things are designed to work.

Something similar applies to the DATA-SOURCE. You have a ProDataSet, a DATA-SOURCE, but the missing piece here is the mapping of a temp-table query to the database query, handled by the DATA-SOURCE (at least a year or two ago).

The effect on the merge is useful information, but my concern is on the commit to the data base and transactions scooping.

I'm sorry I missed the real question.

I guess it is important to stress that the ABL transaction management has not been changed or extended by the introduction of the ProDataSet. If you want multiple changes to be undone on an error, you must ensure that all these changes are done in the same transaction and then undo the transaction when an error is encountered.

save-row-changes will set the error flag on the buffer, table and prodataset when an error is encountered and these flags can certainly be used also within the actual transaction (e.g. higher up in the call stack) to check for errors.

For example adding no-error to save-row-changes may be ok where there is a single transaction, but where there are prior successful saves in a "commit as single transaction" mode earlier transactions are not undone.

The changes that can be undone is decided by the transaction scope as it always has been. You can never undo earlier transactions. save-row-changes is a method and should not throw an error even when used without no-error. You need to do an undo (undo, undo , return error or..) that affects the transaction block. It might be easier to use these attributes for this than propagating errors up the call stack.

Using no-error or not on save-row-changes should not have any effect on what is undone by default or what can be undone by code.

From your answers to date it seems that there is no effect on the server-side of setting error, rejected, or error-string, other than through you code or the code of the framework.

That is correct. I believe the ABL has sufficient support for controlling transaction block execution and undo. If these flags had any direct effect on this they could risk preventing certain modes of operation. (You might for example want to continue the processing after an error just to gather all error messages even if all of the changes eventually is going to be undone)

I think if you read the supporting documents and the welcome postings etc for both Johns original work, and AutoEdge, you will see that both do state the goal of the material. For example:

I don't know if I read these specifically, but was aware they'd be there. However, management who accepted the "product" were not aware and when you know and respect the Progress people concerned, it puts you in a difficult situation. At this site the current development has a tight time frame and we have gone from V9 to V10, to Architect, Webspeed, prodataset, roundtable, a new design methodology and development tracking etc etc - I think I count around a dozen new things. For the application prodatasets are a good choice but then we needed code to support them and this is where OpenEdge came in. But there was no warning, disclaimers or testing suggested from the Progress representative. Now the representative is also in a difficult situation with certain pressures and as I said I respect that person and have a good relationship with them and also there is little proved readily accessible production frameworks for prodatasets as yet. I have a framework myself that was based on the original John Sadd examples that I have tested and proven (to myself), but can't claim that it is a proven production framework.

I believe the ABL has sufficient support for controlling transaction block execution and undo.

That I found out, but when I saw no code in any of the examples (particularly in commitAllChanges) I thought that one of the attributes may echo the error and cause the undo. There is similar code in the work environment and their own version of commitAllChanges that I'm sure will not work correctly.

The reason for the original question was that I noticed that there dataset:error was used in AutoEdge while I had used rejected based on the original code. I thought that maybe something had changed or I was missing something.

There are a number of other concepts that I have used in my framework that is not in the examples such as allowance for calculated fields on save and capturing the fields that have changed and their values where there a current-changed and at the client allowing the user to see and choose the new save values. Regards the latter it would be useful if the dynamic buffer-compare returned a list if fields instead of a logical and better if there was an attribute of method to get the fields that cause current changed and the associated values. But perhaps this can be another topic of discussion if anybody is interested.

Miles