Skip to Content

Job Documentation - deeper dive needed.

Hi, all.

We are a fairly new SAP installation. As such, we've just started implementing background business jobs and have worked our way through the concepts and authorizations needed to get the workflow figured out and activated. In general, we have the process set up so that a user goes into Work Center, enters a job request, I get the request via Incident Management and create the document and get the job scheduled from within Solution Manager (kicks me into SM37 on the required system).

I've gone thorugh the white papers, best practices, etc, and while these are very good for explaining concepts, they don't get into the nuts and bolts of some of the selections that can be made in the process. There are many boxes that get checked in the tutorials/examples that have no explanation of what they do.

eg - http://help.sap.com/saphelp_smehp1/helpdata/en/57/d2cf601a664302a3a0a0dd98b48b31/content.htm

For instance - in Job Documentation General Tab/ Step Overview - what does selecting "client specific" do? What are the ramifications of not choosing it? Can it be defaulted on? All examples seem to select it.

When making job changes (adding a step, for example) - nowhere does any documentation describe how Logical Components afect the change. In order for a change to be reflected in the schedule, the Logical Component that contains the client that the job needs to be run on has to be deleted, change saved, then LC re-added in order for that change to make it to that system/client. Or is there a better way that I'm missing? Seems very clunky.

What are the differences/benefits of using versioning vs creating new documents? ( I do know the difference in the concepts, but in the SAP world, how do they aid the process?)

Why do Jobs get scheduled (invalidly) if there are errors in the job documentation?

Why do job documentss with empty job names and no job documentation get created? (This one has me stumped - I can't figure out which process created these. They seem to be created during an update process but I don't know which ones..)

Lots of questions, I know.. lol.. Are there any documents that dig into these details, or is this all trial and error to find the 'best' method for each customer's implementation?

thanks.

Bernie Krause

Edited by: Bernie Krause on Nov 30, 2011 10:06 PM Typo - meant SM37, not 36

Edited by: Bernie Krause on Nov 30, 2011 10:11 PM

Add a comment
10|10000 characters needed characters exceeded

Assigned Tags

Related questions

2 Answers

  • Best Answer
    Posted on Dec 05, 2011 at 03:09 PM

    Hello Bernie,

    1. Flag "client specific" for job steps:

    This flag is for documentation purpose only and you can use it to indicate if a jobs works on client-specific or on client-independent data. This information is independent from the system client to which the job is scheduled and usually not known to users but developers.

    2. When making job changes (adding a step, for example) - how do Logical Components affect the change.

    The relation is like this:

    Job Documentation 1N Logical Component 1N Logical System (System&Client) 1--1 Schedule

    In which view do you add the step? Documentation or Schedule?

    From your description I guess that you add a step in the "general" tab of the job documentation and that you cannot see that change in the scheduling application.

    As you can see above documentation and schedule are independent objects, each with its own storage and lockign mechanism. Before you add a step to a job documentation you will have to make sure that the scheduling applcation is either closed or in display mode. After adding the step you and save the job documentation. Afterwards you can open the scheduling application again (refresh browser with F5 to trigger a reload).

    3. What are the differences/benefits of using versioning vs creating new documents?

    Versioning of Job Documentation is used together with the life cycle management functionalities of SAP Solution Manager, namely Change Request Management. With each change that could also affect the code of an ABAP report a new version is being generated. If you don't use the Change Request Management integration it's still recommended to use the versioning (if needed) because all versions are easily accessible form the (currently active version of the) job documentation.

    By creation of new and independent job documentation you lose the predecessor-successor relationship.

    4. Why do Jobs get scheduled (invalidly) if there are errors in the job documentation?

    I assume that you use the BC-XBP interface to schedule jobs from the Job Documentation. The XBP interface creates the job as specified in the job documentation. If that job definition is incomplete or inconsistent this will lead to an invalid job in the backend.

    Neither does the XBP interface nor the job documentation undo the change or autmatically delete the invalid job.

    And in fact there's no need to do it because instead you have the chance to complete of fix the job definition in the job documentation and whendone you can just update the job in the backend system and it will become valid.

    Typically this happens due to time difference between Solution Manager and the managed system. If your system landscape is distributed over different time zones I recommend to use SAP CPS by Redwood which includes a time zone handling.

    5. Why do job documents with empty job names and no job documentation get created?

    Such issues could be caused by incorrect CRM customizing in Solution Manager 7.0. You might need the help of SAP Support.

    Kind regards,

    Martin

    Add a comment
    10|10000 characters needed characters exceeded

    • Ok, points 1, 3 thru 5 make sense, and are really helpful. (points will be awarded - lol)

      Point #2 needs more info however. The changes we're usually making are not to add or delete job steps, but to change either program or variant within a step. I'm not sure if that affects the process you've described. I'm not clear on what you mean by "scheduling application" either. I'll give you a step-by-step of our process.

      1) update job document - change step values in General tab

      2) go to system tab - delete logical component that contains target system:client because change is not reflected here. Save

      3) add same logical component, select system:client and click Schedule button.

      4) go to Change mode, select appropriate RFC, date/time, update User name (always defaults to current user), click Create button to create schedule entry in SM37 of target system (refresh button does NOT pick up change from General tab)

      5) log on to target system:client, delete old job and cancel release of new job to set it to scheduled.

      We tried various ways to refresh the job in sm37 today after a change, but I'm not sure that I'm understanding your process.

      Just to clarify - yes, we are using BC-XBP interface for scheduling. We are not using Redwood because, well, "it's not our standard".. sigh.. Control-M is.

      thoughts?

      thanks.

      Bernie

  • author's profile photo Former Member
    Former Member
    Posted on Dec 04, 2011 at 01:22 PM

    Hi Bernie ,

    This is Jacky from the Solman Dev team.

    Would you please list all your questions one by one? so that our discussion can go in an orderly way.

    Best Regards,

    Jacky

    Edited by: Jacky Zhang on Dec 4, 2011 2:22 PM

    Add a comment
    10|10000 characters needed characters exceeded

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.