The reduce loops through 1 journal record for all journal lines with a certain account, does a search to find a purchase order based on a custom field value on the journal line, and then sets the resulting value on the journal line. Doesn't seem like it should be too much governance to me? Though it can run hundreds of times for a single journal entry (meaning there might be hundreds of lines with the relevant expense account on that journal)

reduce code

Assuming I'm right and the 100s of searches is what's hitting the SSS_USAGE_Limit (seems to coincide with the error stack) the only thing I can think of is to loop through the journal twice. Once to get all the po ids, then do a single search to build a big hash map, and then a second loop through the lines to check against the hash map?

The reduce runs... something like 90 times (once per relevant journal entry) though this will increase by 1 every month I think

your implementation will require you to use a bunch of "OR"s in your filter expression, though you can make the search easier for yourself if you can get actual internal ids of purchase orders instead of po number

I'd make a big array and do anyof i suppose

pull all the records with internalid and tranid columns into a big array and then loop through the entries a second time and check the array

Hmm that didnt' save right, I guess Any is just the default dropdown option?

Maybe a query instead of a search at that point? I assume there'll be some governance issue with 1000 tranids

you have the same options

a bunch of ors, or a in condition

with the in condition being limited to 1000 ids before you need to start making multiple of them for the ors

A properly designed Map Reduce will never run out of governance.

also, you could make your input data return only the lines that needs to be updated, on map you find the PO, then on reduce you update all lines together

I still feel like this could be resolved with a query in getInputData that only returns the lines that you need to work on.

Pass all transaction lines to Map. Group them by transaction Id as key and keep all values as values in Reduce, process the lines that are included in values. Preferrably you will include lineuniquekey or lineid from getInputData. You will also retrieve all relevant values from the PO in getInputData as well. So that when you actually update the journal, it will only require the governance units needed for load and save on the journal (perhaps some other small stuff)

Re: Only passing journal lines to map/reduce Currently the getinputdata does 2 things- 1. finds journals with lines with expense account 20003 2. finds inactive vendors associated with those journals and temporarily re-activates them (writes internal ids to a file in the file cabinet then read by the summarize) Then the reduce- 1. Loops through journal, identifying only relevant lines, searches for an associated PO for those relevant lines, then sets the value on the line Summary- 1. re-active vendors inactivated in getinputdata (read from the file in the file cabinet) So I don't understand how finding the lines themselves in getinputdata makes a difference in regards to governance if I kept this same structure? Meaning, in my perspective the thing I need to do is not change what's being passed to the reduce method, but instead simply figure out a way to only perform a single search after having looped through all the journal lines. I do understand how I could potentially find this information in the getinputdata function, but it seems 'cleaner' or better segmented to me to do it in the reduce still (and either loop through the journal twice or use a query b/w the journal and the pos)?

I already have this suiteql for identifying inactive vendors-

var suiteQL = `SELECT V.ID
               FROM Transaction T
               JOIN TransactionLine TL ON T.ID = TL.TRANSACTION
               JOIN Transaction PO ON PO.TRANID = TL.CUSTCOL_AD_PO_NUM_JOURNALS
               JOIN Vendor V ON V.ID = PO.ENTITY
               WHERE T.TYPE = 'Journal' AND V.ISINACTIVE = 'T' AND TL.EXPENSEACCOUNT IN ('${expenseAccountId}')`;

so I assume I can just cut it short and do something like...

SELECT PO.TRANID
FROM Transaction T
JOIN TransactionLine TL on T.ID = TL.TRANSACTION
JOIN Transaction PO on PO.TRANID = TL.CUSTCOL_AD_PO_NUM_JOURNALS 
WHERE T.TYPE = 'Journal' AND PO.TYPE = 'Purchase Order' AND T.ID is ('${journal.id}')

For an idea on total performance, for now the script will be reviewing/updating ~50,000 journal lines, but every month that number will grow (ideally the number that actually are changed dramatically drops after first pass but all 50K+ need to be reviewed for changes every month)

In Luiz proposed division of work across the stages, watch out for two map-instances modifying the same vendor. Also, in reduce. Make sure that you don't have too many vendors to activate again. It need to fit inside the 5000 points.

I do think just doing a query in the reduce statements so it runs once/journal will work but I do agree that journal lines in map and journals in reduce is a better structure

They are sort-of a custom type thing built for a revenue recognition process

which is a single submitfields for each vendor

So I guess it's 350 x 5 which you're right, is still a notable governance but I think still works in my 10K limit for the moment... I don't expect the inactive vendors to dramatically increase in the near future either. And I do need to get these 4 map/reduce done asap also so I think even if a re-factor for vendor activation is needed it can happen after these go live.

Of course time is also a factor not just the raw governance of the api calls. YMMV

And

var suiteQL = `SELECT PO.TRANID, PO.ENTITY AS PO_ENTITY, SO.ENTITY AS SO_ENTITY
        FROM Transaction J
        JOIN TransactionLine JL ON J.ID = JL.TRANSACTION
        JOIN Transaction PO ON PO.TRANID = JL.CUSTCOL_AD_PO_NUM_JOURNALS
        JOIN Transaction SO on SO.ID = PO.CUSTBODY_RSM_SO_REFERENCE
        WHERE J.TYPE = 'Journal'
          AND PO.TYPE = 'PurchOrd'
          AND SO.TYPE = 'SalesOrd'
          AND J.ID IN ('${journalRecord.id}')
          AND JL.EXPENSEACCOUNT IN ('${expenseAccountId}')
          AND PO.ENTITY IS NOT NULL`;

for my customer script which is running now fingers crossed