Enabling Siebel Argument Tracing - Siebel Inbound Webservice Debugging

Enabling Siebel Argument Tracing

---

You can also export input and output arguments in XML format to a file for the EAI Siebel Adapter. These XML files represent the input and output arguments integration object instances. This is a useful technique as it writes to a file the integration object instances in the directory where your Siebel process is running. For example, in the Siebel Developer Web Client, it is c:/siebel/bin.

To enable output arguments tracing

1. Set the server parameter EnableServiceArgTracing to True:
   • If you are running the Siebel Developer Web Client, add the following to your .cfg file:
   [EAISubsys]
   EnableServiceArgTracing = TRUE
   • If you are running the Siebel Web Client, modify the following Siebel Server parameter for your object manager:
   "EnableServiceArgTracing" = true
2. Set the appropriate component event level on your server component through the server manager on the server or SIEBEL_LOG_EVENTS in the Siebel Developer Web Client.
   If you set event to:
   =3, then input arguments will be written out to a file when an error happens.
   =4, then input and output arguments will be written to a file.

Send Email via Siebel Scripting or Object Interfaces Using Outbound Communication Manager

The Communications Outbound Manager processes outbound communications, for email, fax, wireless message, or page channels. It also supports outbound capabilities for Siebel Email Response and for the Send Email, Send Fax, and Send Wireless Message commands.

For further information, refer to Siebel Bookshelf version 7.5.x > Siebel Communications Server Administration Guide > Administering Siebel Communications Server > Administering Communications Outbound Manager.

Here is the eScript sample code:
//—-start

//instantiate the business service and the propertysets

var bs = TheApplication().GetService(“Outbound Communications Manager”);
var inputs = TheApplication().NewPropertySet();
var outputs = TheApplication().NewPropertySet();

//Communication profile to be used – must be must be a current profile defined in the application
var CommProfile = “MyProfile”;

var MsgToList = “s003@myexchangeserver.zeb.com”;
var MsgBody = “Hello testing hello! How are you today?”;
var MsgSubject = “Testing Message”;

//Where C:\ on the Siebel Server or the Siebel Client file system? Or where in a remote client?

var AttachFileList = “c:\\test.txt”;

inputs.SetProperty(“CommProfile”,CommProfile);

//for web client use ‘Remote’ instead of ‘Local’
inputs.SetProperty(“ProcessMode”,”Local”);

inputs.SetProperty(“MsgToList”,MsgToList);
inputs.SetProperty(“MsgBody”,MsgBody);
inputs.SetProperty(“MsgSubject”,MsgSubject);

inputs.SetProperty(“AttachFileList”,AttachFileList);

bs.InvokeMethod(“SendMessage”,inputs,outputs);

inputs = null;
outputs = null;
bs=null;

//—-end

NOTE: The sample code must be thoroughly tested before implementing in the production environment.The above code can be used via Siebel VB or Siebel Object Interfaces.

NOTE: The two arguments AttachFileList and AttachNameList are hiddenarguments belonging to the SendMessage method. Consequently it is possible to use these arguments, but they are technically not supported. As a result the sending of emails with attachments using the Outbound Communications Manager business service SendMessage method in scripting or workflow is not formally supported at present.

AttachNameList is a list of file names, each separated by “*” (asterisk). AttachFileList is a list of file paths, also each separated by asterisk. AttachNameList is optional. If omitted, the names in the file paths are used.

NOTE: The file paths must be accessible from the process that actually sends the email. That means the client process that calls SendMessage if the ProcessMode argument = Local, and the Communications Manager server component if the ProcessMode argument = Remote.

Determining the Workflow Invocation Event

This task is a step in Process of Planning a Workflow Process.

During the planning phase of a development effort you can determine if the workflow process is invoked by a run-time event, user event, workflow policy, or script.

For more information, see Invoking a Workflow Process.

Using a Workflow Policy to Invoke a Workflow Process

A workflow policy triggers a workflow process after a database change. The basic construct of a policy is a rule. If the conditions of a rule are true, then an action occurs. In some cases, the action invokes the Workflow Process Manager server component to execute a workflow process.

Processing invoked by a workflow policy does not occur in real time. Typical uses of a workflow policy include:

• EIM batch processing.
• Siebel EAI inserts and updates.
• Manual changes from the user interface.
• Assignment Manager assignments.
• Siebel Remote synchronization.

Using an Event to Invoke a Workflow Process

Types of events used by Siebel workflow include:

• Run-time events. A run-time event is based in the Object Manager and occurs when a change is encountered by the user interface or in the business component layer. Processing invoked by a run-time event occurs in real time.
• User events. A user event is a unique event internal to Workflow that triggers or resumes a long-running workflow process. A user event is generated by the User Event business service.

Events belong to three objects: Application objects, Applet objects, and Business Component objects. Events can be configured from the administrative interface.

Using Script to Invoke a Workflow Process

Scripts can call a workflow process programmatically as a business service. Using script, you can invoke Workflow from an external system. The Workflow Process Manager server component provides APIs for such programmatic invocation. Scripts are raised by the Object Manager.

Scripts belong to four objects: Application, Applet, Business Component, and Business Service.

Summary of Invocation Mechanisms

Table 9 summarizes the main uses and limitations for each of the possible workflow invocation techniques.

Table 9. Description of Advantages and Limitations of Workflow Invocation Techniques

Invocation Method	Most Useful When	Limitations
Workflow Policy	You must detect and react to data changes made outside of the Object Manager. For example, by Siebel Remote or by Siebel EIM.	Limitations for a workflow policy include: Making changes requires database downtime. Relatively complex to configure
Event	You must implement a basic entry point for a workflow or a simple custom action. You must avoid distributing SRFs. For example, because of the burden created for mobile users.	Limitations for an event include: Cannot directly respond to an event by scripting against the event object Can be more difficult to pass the event context to business logic This invocation technique does not trap data changes made by non-Object Manager components
Script	You need flexibility to write script directly in response to an event. You need access to an applet event that is only exposed in Siebel Tools.	Limitations for script include: Changes must be distributed through a new .SRF. Does not detect data changes made by non-Object Manager components. Note that, for workflow, the script is implemented on a Siebel Tools Object Event.

Siebel Triggers Job Uses only OR logic on Policy Conditions while Creating Triggers

Generate Triggers Job Only Uses "OR" Logic when Creating Triggers

Generate Triggers Job Only Uses "OR" Logic when Creating Triggers

While creating the Generate Triggers job, it is observerd that all the triggers are created with "or" logic even though their policies contain a series of "anded" criteria.

This is the expected behavior.

The triggers created for multiple conditions of one policy with "or" logic is expected behavior.

The reason for this is to separate the functionality of Generate Triggers (Gentrig) and WorkflowMonitor (WorkMon) Components. Gentrig is a relative simple Server Component that monitors DBrecord changes and inserts a record of these changes into S_ESCL_REQ. WorkMon then evaluates the inserted record (violation) and checks to see if all the conditions associated with Rule of the violation are met.  Only if all conditions are met, does WorkMon then fire the associated action for the policy.

Architecturally, it is more efficient to have WorkMon evaluate the conditions associated with a violation rather than having a complex trigger mechanism.  Additionally, because condition data is often stored in more than 1 table; and because a series of conditions that cause a violation of policy can occur at separate times while still within the monitor action interval, capturing these with database triggers is very difficult -because database triggers can only fire for concurrent actions.  As a result of this database limitation, it becomes important to capture all of these potential violations in order to have WorkMon evaluated them as a whole at the time of the policy action.

For example, a policy has 2 conditions: SR area=Network and Activity Priority=1-ASAP. 2 triggers will be generated. One trigger monitors SR being created or updated, and checks to see if the area equals Network. The other trigger monitors Activity records being created or updated, and checks to see if the Priority equals 1-ASAP. If we created AND triggers, and a user creates a SR without Activity, since the activity is not there, the trigger will not be violated. Later, a user adds an activity to the SR, but because the trigger created was using an "AND" trigger, and in this instance the main SRrecord is not updated, still no database trigger fires. The violation would then be lost as no trigger would be fired in either instance due to the anded logic.
However, if the OR logic exists for the triggers, then there will be 2 records inserted into S_ESCL_REQ (1 for the SR area Network added/upated, 1 for the Priority 1 activity added)  Because workMon will evaluate each record as it is inserted, the condition would not evaluate as a violation until the activity is added (the second record).  Therefore, the first row would be discarded (as there was no activity), but the second insert would cause a violation and the action would fire because at that time, both the SR Area and the Activity Priority meet the policy conditions.

So, as you can see when you look at the architecture in its entirety, even though the triggers are generated with "or" logic, the WorkMon component will evaluate the entire rule as a whole before deciding whether or not it is appropriate to fire off the workflow.

Please not that modifying triggers manually is not a supported practice.

Creating VBC in Siebel

A virtual business component (VBC) provides a way to access data that resides in an external data source using a Siebel business component. The VBC does not map to an underlying table in the Siebel Database. You create a new VBC in Siebel Tools and compile it into the siebel.srf file. The VBC calls a Siebel business service to provide a transport mechanism.

 You can take two approaches to use VBCs

• Use the XML Gateway business service to pass data between the VBC and one of the Siebel transports, such as the EAI HTTP Transport or the EAI MSMQ Transport
• Write your own business service in Siebel eScript or in Siebel VB to implement the methods described in this chapter

Creating a custom Siebel Report using BI Publisher

« Previous post

Next post »

How to create a custom Siebel Report using BI Publisher

AUGUST 2ND, 2011. Wilinton

If you’ve ever worked with Siebel Business Applications, you should know that these come with predefined reports composed of integration objects and layouts.
These applications can be customized by modifying an integration object and/or RTF template when necessary. Sometimes the predefined report doesn’t match with user requirements (based on our experience this happens most of the time), however, there exists the possibility of creating a Siebel Report from scratch.
This article is a road map on how to create a custom Siebel Report in a connected mode.
The following steps list the process of how to create a custom Siebel Report:

1. Create a Siebel integration object
2. Generate an xml data file to use it as a data source during template developing
3. Create a template using BI Publisher Add-in for MS Word
4. Upload the new template to Siebel

Create a Siebel Integration Object:

In this first step you will use the Integration Object Builder wizard to create an Integration Object using Siebel Tools.

BI Publisher is integrated with Siebel through web services as it is necessary to create or reuse a Siebel Integration Object. This step provides a hierarchical structure of data.

Figure  1, the Integration Object Builder wizard.

Once the integration object has been created, you have to deploy it to runtime database. One of the main advantages of BI Publisher as a reporting tool is that the compilation of the SRF file is not necessary in this step.

Figure 2, Integration Object and Integration Components

Generate an xml data file to use it as a data source during template developing
Now you will generate xml sample data. In Sample Data File Generation Siebel View, select the new Integration Object, generate Sample XML and save the file. This process extracts a subset of data that you will use to build the RTF layout. In a case where the complete hierarchy is not generated in this subset of data; you must generate a XSD Schema of your integration object using the Generate XML Schema Wizard in Siebel Tools. Remember to save it as a XML file.

Figure 3, Sample data file and schema generation

Create a template using BI Publisher Add-in for MS Word
Now you are ready to build your RTF layout. Use BI Publisher Add-in for MS Word to load the XML file which you generated in the previous step. Build your template using XML tags from the Integration Object and check if the report preview is working.

Figure 4, Load Data or Schema in BI Publisher Add-in

To generate the XLIFF file in MS Word go to Translate Template, then Extract text and save it with an xlf extension.

Figure 5, Creating XLIFF file

Upload the new template to Siebel
Once you have your template finished, it is time to register it. In Siebel Application, go to template view and create a new report. Select the report layout, XLIFF file and assign the Integration Object. Associate the Report with a Siebel Applications view and upload the file.

Figure 6, Template Registration

Your report is now available in the view you have associated it with. From this point you can run or schedule your new custom report.

In conclusion, you would need to create a customized Siebel Report when any of the existing predefined Siebel reports does not match your reporting needs. However, you have to be familiar with all these predefined reports so that when you go to analyze the requirements you can be completely sure that you need to build that report and not spending your time reinventing the wheel.

- See more at: http://www.clearpeaks.com/blog/oracle-bi-ee/how-to-create-a-custom-siebel-report-using-bi-publisher#sthash.MmsVvKeK.dpuf