Ariba Buyer 9r1: Using the command line option, -norestart for startbuyer, without the NodeManager running, for local development commonly makes restarts faster. However, it can produce the following error message:

Service clients Ariba Access https://connect.ariba.com to connect!

Ariba Buyer 8.2.2:  While developing a catalog, you can create a watcher and approver (different users) in the approval flow. Add the watcher and approver, with specific roles, while creating a requisition and selecting the items from the specific catalog.  

Because you cannot specify the same commodity code twice within the Server\config\variants\var1\data\CommodityApprovers.csv file, use two Comma Separated Value (CSV) files:

• The first rule uses the approver CSV file to add the approver to the approval graph, as soon as you select the particular commodity code.
• The second rule uses the watcher CSV file to add the watcher to the approval graph, as soon as you select the particular commodity code.
  

Create those rules in Administrator-->Rule Editor-->Edit JavaScript Requisition Rules, adding each as a simple rule and designating it as the "Commodity CSV rule" type.

While creating the Commodity CSV rule, you can specify the CSV file and save it. When you attempt to edit this rule, if the software does not find that CSV file, it asks whether it can create a new CSV file, giving you the opportunity to do so.

Use these easy-to-follow steps to complete the Archive and Purge process in Ariba^� Buyer^TM 8.2.2 effectively. This long process usually takes a few months. 

1. Backup the Ariba Buyer database (DB) of the instance in which to run these scripts.
   
2. Get the PRE-PURGE numbers from Inspector.
   
   
1. This important step depends on your requirement. Define the objects to purge in an Extensible Markup Language (XML) file. (See the Ariba Buyer Configuration Guide Version 8.2 for a detailed description of that file and its purpose.) At this point, you can already catch quite a few issues. They usually appear on the WHERE conditions. Make sure to get the number of objects corresponding to exactly the same query from the XML file:
   
   SELECT COUNT(*)
   FROM ariba.purchasing.core.Requisition
   WHERE (StatusString != 'Canceled'
   AND StatusString != 'Composing')
   
   
2. Verify that all of these objects are in PurgeState = 0:
   
   SELECT COUNT(*)
   FROM ariba.purchasing.core.Requisition
   WHERE (StatusString != 'Canceled'
   AND StatusString != 'Composing')
   AND PurgeState = 0
   
   
3. Verify that the PURGE_CANDIDATES table is empty!
   
   
1. Go to inspector > Purge Browser: nothing should display
2. Go to inspector > Query Statement and run the following query, which should return a message similar to "Cannot find class PURGE_CANDIDATES":
   
   SELECT COUNT(*) FROM PURGE_CANDIDATES
   
   
3. Run the PREVIEW phase as indicated in the previously mentioned documenation.
4. Verify the candidate objects by starting Ariba Buyer and going to inspector/PurgeBrowser. Here, you frequently see inconsistencies between the numbers from the purge browser and the queries you ran before the PREVIEW phase. This can happen because the PREVIEW phase numbers also include dependencies between objects that your queries could not see, necessarily. At this point, the DB is not changed, and no object is marked. Also, get some numbers from the PURGE_CANDIDATES table, and verify that the PURGE_RECORD (which will contain the references to all objects we want to purge and archive) is empty. 
   
   + SELECT COUNT(*)
   FROM PURGE_CANDIDATES
   
   + SELECT COUNT(*)
   FROM PURGE_RECORD
   
   COUNT(*)
   0
   
   
5. Run the MARK phase as described in the previously mentioned documentation.
   
6. After the MARK phase completes:
   
   
1. Verify the numbers, again, for each type of object as in Step 2. To do so, add the following condition to your queries:
   
   et PurgeState > 0
   
   At this point, Ariba Buyer cannot access any of the objects marked to purge. 
   
   SELECT COUNT(*)
   FROM ariba.purchasing.core.Requisition
   WHERE (StatusString != 'Canceled'
   AND StatusString != 'Composing'
   AND PurgeState > 0)
   
   
2. Check the number of objects in the PURGE_RECORD and PURGE_CANDIDATES:
   
   + SELECT COUNT(*)
   FROM PURGE_RECORD
   
   + SELECT COUNT(*)
   FROM PURGE_CANDIDATES
   
   
7. Run the ObjectArchive task as described in the previously mentioned documentation.
   
   Important: Once you start the ARCHIVE phase, you cannot run any part of the PURGE phase on the same DB! If you must run the PURGE again, you must start from a fresh DB backup.
   
   Usually, changing two things gets the objects purged and archived as fast as possible. They involve letting the task go as far as possible and reducing the number of times it must run. Use these at your discretion depending on your specific configuration and requirements.
   
   Set MaximumAllowedErrors = 10000;
   And set IgnoreBadFieldValue = true; 
   
   
   ObjectArchive = {
           Directory = objectArchive.10.08;
           IgnoreBadFieldValue = true;
           MaximumAllowedErrors = 10000;
           PurgeScope = Procurement;
           RunningTimeInMinute = 480;
           ScheduledTaskClassName = ariba.encoder.soap
               .base.ArchiveTask;
           SleepIntervalInMillis = 5000;
       };
   
   
8. After the Archive task completes, check the logs and the number of entries in "failed" state by running the following query:
   
   select count(*) from PURGE_RECORD
   where STATE = 2
   
   Note:  At this point, no table entries should have "STATE = 2". If any appear, the Archive task probably is not finished yet.
   
   
9. Run the FailedObjectArchive task. This task attempts to archive the objects in the error state, only. The following errors usually appear in the logs:
   
   
1. Null Pointer Exceptions: usually indicate one of the following:
   
   
• may require a code fix from Engineers
• the existence of references to non-existing objects caused by a deleted user, deleted requisition, or a missing attachment
  
  
2. Catalog Errors
   
3. Wrong Binary (BIN) attachments in Archive directory: most of the issues occur on Microsoft^� Office Word^� document files (DOC) or Microsoft^� Office Excel^� Spreadsheet (XLS) files, again, depending on the specific configuration. In one case, the following fixed the problem (after finding that the problem occurred on DOC and XLS files):
   
   
1. Get the numbers of documents to update:
   
   SELECT count(*)
   FROM AttachmentTab include inactive
   WHERE AT_CONTENTTYPE = 'application/octet-stream'
   AND AT_EXTENSION = 'doc'
   
   SELECT count(*)
   FROM AttachmentTab include inactive
   WHERE AT_CONTENTTYPE = 'application/octet-stream'
   AND AT_EXTENSION = 'xls'
   
   
2. Update these objects, making sure that the content_type is supported by our code:
   
   UPDATE AttachmentTab
   SET AT_CONTENTTYPE = 'application/msword'
   WHERE AT_CONTENTTYPE = 'application/octet-stream'
   AND AT_EXTENSION = 'doc'
   
   UPDATE AttachmentTab
   SET AT_CONTENTTYPE = 'application/vnd.ms-excel'
   WHERE AT_CONTENTTYPE = 'application/octet-stream'
   AND AT_EXTENSION = 'xls'
   
   
3. For real BIN attachments: some extensions are not supported, such as Microsoft^� Office Outlook^� Message (MSG) Format, "DOC=", or no extension. Usually, they represent a very small number.
   
   
4. Zero kilobyte (0kb) attachments: some are 'real' 0kb files, some appear to be 0kb files because the attachment is missing from the customer file system. The following query identifies the 'real' 0kb files.
   
   SELECT Comments.Attachments
           .ContentLength,
       Comments.Attachments
           .Filename,
       Comments.Attachments
           .Extension,
       Comments.Attachments
           .ContentType,
       Comments.Attachments
           .StoredFilename
   FROM Requisition
   WHERE Comments.Attachment
       .ContentLength = 0
   
   
10. Check the number of objects again to determine if any remain in the DB. A few objects may not be archived, but you usually find that acceptable, or can explain it. Also, after the Purge and Archive process, no entries should appear in the PURGE_RECORD table. 
    
    
    SELECT COUNT(*)
    FROM PURGE_RECORD
    
    COUNT(*) 

The Fixed Defects portlets on the connect.ariba.com Product Info pages have a new column entitled "Requires Action." This new column highlights fixed defects that require action from an administrator to take advantage of the fix or new feature. Click the column header to sort these fixed defects together. Click the View All Fixed Defects that Require Action in One Document link to see the full details on one page.