JDE E1 "unit of work"

JDE E1 \"unit of work\"

Hi everyone,

I had this question in the back of my mind for a while, and now Management is asking me the same thing: how do we measure a JDE's unit of work or transaction?

What we are trying to find here is an unit of measure to understand if our complex JDE infrastructure is processing more jobs than last month or last year. So far we have measured total amount of users -which may mean nothing for workload- , or total amount of batch jobs, but I can' find anything I could use as "interactive transactions" or something of the sort.

One of the pieces of information that frustrates me most is I do have that information in the Server Manager. I could see business functions, the number of times they were processed, and their average processing time. If there were a way to save that information in a table I'll be more than happy.

So, in summary: has anyone had the challenge of measuring transactions / response time? Oh has anyone gone through the process of saving Server Manager's BSFN information?

Thanks

Alberto

Re: JDE E1 \"unit of work\"

Can you try to do something with the data instead. Like total number of sales or purchases for the last year and this can be checked based on the status in sales order ledger and purchase order ledger. I think this would be a better approach. but i dont know if this is your requirement. Can you elaborate on the requirement ??

Re: JDE E1 \"unit of work\"

Perhaps you are better determining the number of JDE documents being created or processed rather than counting the number of times a function runs. Query the business data tables to gather the number of Purchase Orders, Sales Orders, Work Orders, Vouchers, Receipts, Invoices, Completions etc.

Just a thought ...

Re: JDE E1 \"unit of work\"

Thank you very much for your answers.

I'll try to elaborate a bit more on my question. I would like to have a number representing performance behavior. In an ideal world I'd like to measure the time it takes from end to end to finish all transactions, get the average time per day, and use that number for my SLA (i.e. transactions below 2,000 milliseconds). Since I do not have a way to measure actual transactions from end-to-end I'm trying to create my own unit of measure, which could be the time used by BSFNs . That information exists in the kernels, is displayed by the Server Manager, although I can not store it on a table for trending analysis. By doing something like the above I could get two values: amount of calls to BSFN and response time.

You both have a very good point, I could also count and compare documents created. Although by counting documents I will have an idea of total amount of work (i.e. if in April JDE processed more transactions than in May), but not the time component.

Any crazy idea will be welcome. Thanks.

Re: JDE E1 \"unit of work\"

it will be better if you can use a realistic calculation like so many transactions in a month, so many transactions in a year. based on the hrs of work per day you can now calculate... instead of using BSFN performance.

Re: JDE E1 \"unit of work\"

All,

I just got this from Oracle Support:

"The Runtime Metrics cannot be exported. The answer can be found in attached Document ID: 660320.1. Below I will paste in an excerpt from the document."

"Runtime Metrics in SMC for EnterpriseOne provides metric information for User Sessions (HTML Server Only) among other metrics. This "on they fly" data is not stored in any table or view.
This information is actually stored in Java memory inside the java process that runs in the Management kernel. This data is only viewable from within Server Manager Console and cannot be captured or ported out."

So since this is a dead-end I'll explore the suggestions you gave me. Thanks to everyone !

Alberto


"The Runtime Metrics cannot be exported. The answer can be found in attached Document ID: 660320.1. Below I will paste in an excerpt from the document." "Runtime Metrics in SMC for EnterpriseOne provides metric information for User Sessions (HTML Server Only) among other metrics. This "on they fly" data is not stored in any table or view. This information is actually stored in Java memory inside the java process that runs in the Management kernel. This data is only viewable from within Server Manager Console and cannot be captured or ported out."