New to AWE. I have a situation where data and/or configuration and/or code has become "broken" or scrambled or corrupted while building this approval process.
I'd like to clear out all stuck transactions and start again.
Monitor Approvals has the status for all approval process as status = 'Approved'. They are not. So, I'd like to just clear out all the transaction data and start again.
Which tables do I need to clear out (update and/or delete)?
I've found that since AWE is (for now) built on top of plain, old Workflow I was able to get myself out of trouble by simply updating the Worklist items' status to approved for the user, and clearing the header and XREF tables:
update psworklist set inststatus = 3 where oprid='TheUser';
delete from ps_your_xref;
delete from ps_your_header_rec;
Warning: This might well be a very cowboy approach, has worked fine for me in Development.
Related
Extremely weird bug we’ve been facing today.
We have an iOS app which has updated a document using Realm SDK and I know it has been pushed successfully because I checked the forCurrentlyOutstandingWork session to confirm a 100% upload and also opened up another device to validate if it got the new updated information and it has.
The problem is even though Realm clients across multiple devices are showing the new updated information, the MongoDB doesn’t show the new updated information. It did update after 15 mins automatically but this issue happened to us multiple times today.
Has anybody else faced this issue and found a solution to it ? Or should this never happen and we need to report a bug ?
TIA
Edit:
Realm sync write log -
Logs:
[
"Upload message contained 1 changeset(s)",
"Integrating upload required conflict resolution to be performed on 0 of the changesets",
"Latest server version is now 249"
]
Partition:
1
Write Summary:
{
"Image": {
"updated": [
"612ce539db1dbb2655f6c723"
]
}
}
This was an issue in MongoDB/Realm. I reached out to the support and they resolved it by pushing an update on the 9th of September 2021.
The replication to MongoDB is asynchronous due to the fact that conflict resolution must be performed against incoming writes from MongoDB clients (which sync does not control), to prevent the situation where a write made to MongoDB and a write made by a Realm client pass right by each other and leave the two states inconsistent. Ideally, these writes should happen within a few milliseconds but some latency can occasionally occur (especially around server restarts), but we closely monitor this and are always looking to optimize this.
Engineer on the Sync Team
I am in the process of integrating Workfront with my company's financial software and one of the processes we are trying to automate is the transfer of hours from one project to another in a scenario where hours need to be massaged for billing purposes. Generally, we are looking to transfer hours for a single user from one project to another. In cases where either the associated PROJ is closed or the associated TSHET is closed, is it possible to reopen these, at least temporarily via the API?
Sure, you can re-open them by changing the status. You can also subsequently re-close them once you're done with your tasks.
For a timesheet, you'll just change the status to 'O' as follows:
PUT https://<site>.my.workfront.com/attask/api/v9.0/TSHET/<uuid>?status=O&apiKey=<api key>
For a project, you'll need to know what type of status you want to go back to (you may have a workflow such as new->open->in progress->implementing->testing->closing->closed and you want to go back to 'closing'. Find the 3-character key for that status and update the status as follows:
PUT https://<site>.my.workfront.com/attask/api/v9.0/PROJ/<uuid>?status=<key>&apiKey=<api key>
Closing them again would just involve setting the timesheet to C and the project to whatever its old status was.
We have a long request that does a catalog search and then calculates some information and then stores it in another document. Do call is made to index the document after the store.
In the logs we're getting errors such as INFO ZPublisher.Conflict ConflictError at /pooldb/csvExport/runAgent: database conflict error (oid 0x017f1eae, class BTrees.IIBTree.IISet, serial this txn started with 0x03a30beb4659b266 2013-11-27 23:07:16.488370, serial currently committed 0x03a30c0d2ca5b9aa 2013-11-27 23:41:10.464226) (19 conflicts (0 unresolved) since startup at Mon Nov 25 15:59:08 2013)
and the transaction is getting aborted and restarted.
All the documentation I've read says that due to MVVC in ZODB ReadConflicts no longer occur. Since this is written in RestrictedPython putting in a savepoint is not a simple option (but likely my only choice I'm guessing).
Is there another to avoid this conflict? If I need use savepoints, can anyone think of a security reason why I shouldn't whitelist the savepoint transaction method for use in PythonScripts?
The answer is there really is no way to do a large transaction that involves writes, when there are other small transactions on the same objects at the same time. BTrees are supposed to have some special conflict handling code but it doesn't seem to work in the cases I'm dealing with.
The only way I think to manage this is something like this code which breaks the reindex into smaller transactions to reduce the chance of a conflict. There really should be something like this built into zope/plone.
Right now I have been givin a controlfile some backupfiles and an spfile.ora
How do I apply these to a database on a server that is not the one they were created from.
If further info is needed please let me know. I am eager to get this process laid out for the next time I have to accomplish it.
I have tried to look up the process but keep seeing things about catalogs and such that I don't feel apply to this situation.
Thank you in advance.
EDIT:
I believe I have thr right files but this is where im currently stuck -
RMAN> recover database;
Starting recover at 25-JUL-13
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=770 device type=DISK
starting media recovery
unable to find archived log
archived log thread=1 sequence=6173
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 07/25/2013 20:49:59
RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 6173 and starting SCN of 10866915410156
The answer to my question ended up being to run recover database with the noredo option. Then to open the database use alter database open resetlogs;
recover database noredo;
Hope this might help anyone who runs into the same issues and sorry I couldn't lay out a better explanation.
I have setup the AIF so that when an invoice is created, it gets added to the queue. I know that this doesn't work when Printing to Screen. So I had adjusted the print management settings for that customer to Print to Archive. However, the document still doesn't get added to the AIF queue.
After some investigation, I've found out why. Even though I have "Use Print Management" ticked in the Posting box for posting an Invoice, Under the Printer Setup I have "Send To" set to screen still, when I change this to Print Archive my document gets added to the AIF queue.
So my question is, why is this the case? Why doesn't it pick up what I have set in Print Management for that customer?
I attempted to recreate your issue, but it worked for me just as you would have expected. Perhaps your customer print management isn't set up correctly.
To change my test customer's print management settings, I went to the customer in the customer master form, click Setup -> Print management. Expanded Module -> Account -> Documents -> Sales order invoice. Right-clicked on Original and clicked Override. Then I overrode the default printer destination for that customer.
Follow those steps if you haven't already, and let me know if that works. If not, there may be some other problem.
Are your printers configured as AOS printers? See Classes\SalesFormLetter\checkAOSPrintersPrintManagement
Does this have the same issues in your test environments? Try resetting your usage data. There is a usePrintManagement variable packed in the invoicing process.
If you can debug this, it should be fairly easy to step through and see if print management is actually getting used.