Skip navigation

Earlier this month, we discussed how providing the right information / files at service request creation can substantially improve the time it takes to resolve issues logged with the Siebel technical support team.  For that discussion, please seeRight Information Equals Faster Resolutions to Service Requests.  During the next few blog updates we would like to explore some best practices around file attachments beginning with how the attachments are named.


It is important to understand that in most cases it is best to simply attach the file with the exact name it already has on the system unless the support engineer has specifically requested you rename it.  For example, it is generally not necessary or advisable to rename the siebns.dat file, .srf files, configuration files, or log files.  The internal systems we use have various tools that can help speed up the analysis of many files but they rely on the files having predictable names.  Even when these tools are not available for a specific situation, the support engineer will be looking for specific naming conventions and -- especially when many files have been attached -- significant time can be lost in trying to figure out what "attachmentA.txt" really was.  The same concept applies to changing the extension on the file.  If you are attaching "siebel.cfg" do not rename it to "siebel.txt" or some other extension.  It just confuses things and can add unnecessary delay into the resolution process.


Now in some cases you may need to attach the same file from different systems or from different times.  In these cases you will need to modify the name since My Oracle Support (MOS) will not allow you to attach two files with the same name to the same service request.  In these cases, a best practice is to add some additional info immediately before the period ('.") preceding the extension.  Do not add the information at the beginning of the file name or after the extension.  For, example if you need to attach multiple copies of "siebel.cfg" you might name them as:


  • siebel_a.cfg
  • siebel_b.cfg
  • siebel_c.cfg


When you do rename files in this manner, it is helpful to include a clarifying note either on the upload screen or in a separate note on the service request so that we know what _a, _b, and _c are.  You can also use dates (avoid slashes in the name), the machine name, "new", "original", etc. to help clarify what makes this siebel.cfg different from another siebel.cfg file you have attached.


Finally, sometimes you may be asked to attach files which do not have preset names in the system.  Some examples of this would be screenshots, detailed description of your architecture, reports, etc.  In these cases leave the file extension alone and try to make the name descriptive of the content of the file.  Use the notes on the file upload screen or a update to the service request to further explain what the file is.  Some good file names would be things like:


  • Error_Screenshot.jpg
  • Working_Screenshot.jpg
  • Development Infrastructure.doc
  • QA Infrastructure.doc


If you are ever unsure about the best name to attach the file with, simply ask the support engineer for guidance.  By working together we can make sure that the right files can be quickly identified and analyzed properly which ultimately leads to a faster resolution of your issue.

When an issue arises in a Siebel implementation, we all have the same goal -- to get the issue resolved as quickly as possible.  If you have gone through the My Oracle Support Accreditation Process, you know that one of the items that is covered is creating a well formed and complete service request.  A key part of that is making sure that the correct files and other supporting information is provided as soon as possible (preferably at the beginning) of the service request process.  As an Oracle support engineer, I can say without hesitation that failure to share the correct information is probably the biggest preventable delay in resolving service requests.  So the question becomes what information is needed to successfully start work on a service request?


The answer to that question depends on the specific issue you are facing.  Siebel is a vast product with a large number of integrations and functionalities.  The specific files and information required to resolve one type of issue may be very different than those required to resolve a different issue.  So what is the solution?  Enter "Service Request Data Collection" documents or SRDCs.


SRDCs are a special type of knowledge document in My Oracle Support that outlines the specific files and other information that a Siebel support engineer needs to begin EFFICIENTLY working on your issue.  SRDCs are available in a number of areas at this time and we are constantly adding new ones.  These special documents are created by experienced support engineers in their areas and reviewed by recognized subject matter experts within the Siebel Support organization.  For example, if you are experiencing a crash situation on a Windows server, you would probably want to take a look at DocID 1630675.1 -- "SRDC - What data does Oracle Support need to troubleshoot a Siebel Application crash on Windows?".  


SRDCs can come up in several different ways:


  1. You can do a search on the keywords SRDC Siebel to find all available SRDCs.
  2. During your service request creation process you may be guided to an SRDC.
  3. The support engineer assigned to your service request may refer you to an SRDC.


As always we appreciate your feedback and comments on any knowledge document and that includes SRDCs.  You may use the links provided on the actual SRDC or start a thread within the appropriate Siebel My Oracle Support Community.

Welcome to the My Oracle Support Community! We highly encourage you to personalize your community display name to make your activity more memorable. Please see for instructions.