Report Interconnection & Job Status Issue

abhay123

Active Member
Hi All,

I am trying to retrieve job status of a UBE after calling it from the report interconnect. I need to perform some process after the UBE has completed successfully. In my case I’m calling R42565 from button clicked event, once this report will generate an invoice number based on that performing some update in the custom table and some more process like calling some other form, enabling disabling controls etc.
Now what is happening invoice number not generated and next code getting executed… checked many posts related to this, but didn’t found any relevant because most of the business functions are client only which are stated to retrieve job status. I would really appreciate if anyone could help me this to crack this logic.

Regards,
Abhay
 
Try using the End Report level event in R42565 itself.

It executes when the UBE is over/about to end and free up the kernels etc.

There are loads of posts here on getting job status by the way. Look for B984054 to get your job number then use an OCM override to point to F986110. There's a BSFN for that too, B9861101
 
Thank you John. I appreciate your response to this, but in my case I need to perform some process which is related to application and can't be controlled from the end section of the report. There are lots of posts to retrieve job status, but none of them working correctly as most of the bsfn used to retrieve job status are client only bsfn.

I would really appreciate if anyone help me to accomplish this.


Try using the End Report level event in R42565 itself.

It executes when the UBE is over/about to end and free up the kernels etc.

There are loads of posts here on getting job status by the way. Look for B984054 to get your job number then use an OCM override to point to F986110. There's a BSFN for that too, B9861101
 
It seems you are fighting the nature of asynchronous processing. The application and UBE are not connected in terms of logical flow. If you have custom actions that need to process after invoice print, perhaps create a UBE "wrapper" that calls R42565 synchronously and does the work after. So the app would call the custom UBE instead. As for the app "waiting" for the UBE to complete, there is no magic. It could take seconds or hours and I don't think the UI should loop/wait for anything like that. Maybe a row exit for the custom actions that only executes when the order is at the proper status (bumped by R42565). Or even a separate app to work with orders at that status. Without more details of the requirement, it's difficult to be precise with a suggestion.

Craig
 
Here is scenario…

We have designed a custom application which is going to use by pharmacy retail shop to generate order & Invoice. I had given four buttons on a headerless detail form Generate Order, Regenerate Order, Generate Invoice, Regenerate Invoice.

Once user click on generate order, we are calling the custom report which is creating order in F4201 & F4211. On the same button I need to check whether order got created successfully or not based on that inserting data into custom table and enabling regenerate order & Generate invoice button also disabling generate order button for that particular.

Same we are doing on the invoice button we need to check job status and once it is completed than same process update custom table with invoice number & enable disable button accordingly.

Thanks in advance...
 
Try calling the UBE using the business function B91300C . The business function can launch a batch (with no UBE interconnect ) and will return the job # and with that you can find the job status from F986110 . If you need report interconnect , make a copy of B91300C and then in the business function include the .h of the report you want to call and pass (here R42565.H , invoice ) ,create the structure and object , assign the values from LPDS to your DSTR and then pass in API Launch UBEXX and that should do it .We have done this for many of our cases and designed solutions and it works fine .
 
So the main reason you need this is to check 'automatically' if the order was created successfully and then allow them the ability there and then to regenerate it....?

If they were able to do this.....why do you think it would work the second time without the user changing anything in the mean time?

As the point I'm pushing at is, I don't think you need all this to be as automated and as instant as you think. (I think the job # is not needed, but the NXTR is) As without user intervention to fix the orders issues, it would never work a second time.
The job number sounds irrelevant, as your issue is not the job but the invoice or the final NXTR of your SOs

I would add a button at the top of your screen to go and check the order based on a selected grid record. Or a refresh style button that shows the records are in process or done/error.
I don't think you need the actual UBE job number at all to do what you want to do
 
Last edited:
I'll echo some of the same thoughts others have. I think Craig tried to convey that your overall design is not very practical for the E1 app engine. You should not be submitting reports in an application that needs to know the results of the submitted report. Unless you can know for sure, in every case, that the submitted report will run quickly and in its own jobque, this is just not a good idea.

I am confused about the use/reason of the "Regenerate" buttons. What exactly is the reason for those?

One thing I'd try to do for the "Generate" order logic is to move the logic from your report into a BSFN. That way you can know exactly when that processing is done. If you need the actual output of the report, then create a new report just for formatting your data that can be submitted from the BSFN, but let the BSFN do the work of creating the order.

As for knowing when R42565 is done... you will need to implement something like others have suggested (getting the job# and checking status). This does require user action, however. You would need to provide a button or similar ("refresh") that they could periodically press to check for said status. You could also insert at various points in the report some kind of status updating like writing information to a table that can be checked during the "refresh" processing.
 
I agree with JMR that cloning the report logic into a BSFN is probably the cleanest approach, if for no other reason than being able to present the user with meaningful messages if any errors occur.. I did this once when I needed to automate the payroll interim workbench specifically for grossing-up non-cash employee awards (well before Orchestrations were available!).
 
Try calling the UBE using the business function B91300C . The business function can launch a batch (with no UBE interconnect ) and will return the job # and with that you can find the job status from F986110 . If you need report interconnect , make a copy of B91300C and then in the business function include the .h of the report you want to call and pass (here R42565.H , invoice ) ,create the structure and object , assign the values from LPDS to your DSTR and then pass in API Launch UBEXX and that should do it .We have done this for many of our cases and designed solutions and it works fine .
Hi jdedwardsuser,
Would possible to share a sample code as suggested. Since im new for this .c program editing and user require to do same .
need to a ube interconnect to another ube from with parameter also need get the job number to distinct what job should be called .

Appreciate for your kindly advice
 
Back
Top