Caveat Emptor. Configuration steps below are to give you an idea. I am posting this after I finished to highlight what I recall as the important pieces so not every step is included. You will need to create the new custom table CX_TMPL (or use another), create all links, applets, view objects, make BO/Screen changes and deploy them.
First I build a view with the same IO BC based applet as the vanilla view on top, and child applets for both attachments and a new object which is essentially a search spec. First the attachment bc. This is a new BC which you can copy from an existing attachment BC and change the names around. Here is mine, called 'Sample IO Attachment' based on S_FILE_ATT. Use the field name prefix 'Sample' instead of which ever prefix is used on the BC you are copying (Be sure to set the User Property DefaultPrefix to 'Sample' too):
Name | Join | Column | Force Active | Predefault Value | Text Length | Type |
---|---|---|---|---|---|---|
IO Id | PAR_ROW_ID | Y | Parent: 'Repository Integration Object.Id' | 15 | DTYPE_ID | |
Parent Key | X_PARENT_KEY | Parent: 'Repository Integration Object.Name' | 100 | DTYPE_TEXT |
The Search Spec applet is based on a custom BC, 'Report IO Sample File Template', based on the new table, CX_TMPL (I use this table for other things too so I type spec each record):
Name | Join | Column | Force Active | Predefault Value | Text Length | Type |
---|---|---|---|---|---|---|
Name | NAME | Field: "Id" | 100 | DTYPE_TEXT | ||
Parent Id | S_INT_OBJ | ROW_ID | Y | Parent: "Repository Integration Object.Id" | 15 | DTYPE_ID |
Parent Name | PARENT_FLD | Parent: "Repository Integration Object.Name" | 50 | DTYPE_TEXT | ||
Search Specification | CONSTRAINT | Y | 250 | DTYPE_TEXT | ||
Type | TYPE | SAMPLE_IO_CONSTRAINT | 30 | DTYPE_TEXT | ||
Number of Records | LN_NUM | 10 | DTYPE_INTEGER |
The join, S_INT_OBJ, is based on the specification of Parent Name = NAME. Using name instead of Id allows the search specs to remain visible after repository moves.
You will also need the following Named Method User Property:
"GenerateConstrainedData", "INVOKESVC", "Report IO Sample File Template", "Workflow Process Manager", "RunProcess", "'ProcessName'", "'Export Sample IO To File'", "SearchConstraint", "[Search Specification]", "'IOName'", "[Parent Name]", "Path", "'..\XMLP\Data'", "Object Id", "[Parent Id]", "PageSize", "[Number of Records]"
This user property is to activate the button you will need to place on the applet based on this BC. On that applet (based on class CSSSWEFrameListBase), add a button which invokes the method 'GenerateConstrainedData'. No additional script should be needed there.
Create a Service Flow Workflow Process called 'Export Sample IO To File'
Here are the Process Properties:
Name | In/Out | Data Type |
---|---|---|
FileName | In | String |
IOName | In | String |
PageSize | In | String |
Path | In | String |
SearchConstraint | In | String |
SiebelMessage | None | Hierarchy |
ViewMode | In | String |
The first 'Echo' step is a Business Service based on Workflow Utilities, Echo method. This step sets up all the variables used later in the process. Here are the arguments:
I/O | Argument | Type | Value/Property Name |
---|---|---|---|
Input | IOName | Process Property | IOName |
Input | PageSize | Process Property | PageSize |
Input | Path | Process Property | Path |
Input | SearchConstraint | Process Property | SearchConstraint |
Input | ViewMode | Process Property | ViewMode |
Output | FileName | Expression | IIF([&FileName] is not null, [&FileName], [&IOName]) |
The next 'Export IO' step is a Business Service based on EAI Siebel Adapter, QueryPage method. This step queries the integration object. Here are the arguments:
I/O | Argument | Type | Value/Property Name |
---|---|---|---|
Input | OutputIntObjectName | Process Property | IOName |
Input | PageSize | Process Property | PageSize |
Input | SearchSpec | Process Property | SearchConstraint |
Input | ViewMode | Process Property | ViewMode |
Output | SiebelMessage | Output Argument | SiebelMessage |
The next 'Write to File' step is the Business Service, EAI XML Write to File, WriteEAIMsg method. This step writes the property set out as an XML document to the file system. Here are the arguments:
I/O | Argument | Type | Value/Property Name |
---|---|---|---|
Input | FileName | Expression | [&Path]+"\"+[&Process Instance Id]+"_"+[&FileName]+".xml" |
Input | SiebelMessage | Process Property | SiebelMessage |
The final 'Attach' step is another Business Service, this one custom. The basic logic here is to add an Attachment to the file system which is first described in Oracle document 477534.1 (I have made some improvements which I will perhaps discuss another day). Here are the arguments:
I/O | Argument | Type | Value/Property Name |
---|---|---|---|
Input | AttBusinessComponent | Literal | Sample IO Attachment |
Input | AttachmentFieldName | Literal | SampleFileName |
Input | BusinessObject | Literal | Repository Integration Object |
Input | File | Expression | [&Path]+"\"+[&Process Instance Id]+"_"+[&FileName]+".xml" |
Input | ObjectId | Process Property | Object Id |
Input | PrimaryBusinessComponent | Literal | Repository Integration Object |
Intriguing read! The concept of a "BI Developer Superview" sounds like a fantastic way to foster collaboration and streamline business intelligence efforts. I especially appreciate your breakdown of key roles and their contributions to BI projects. By the way, for those wondering what is a BI developer, it is someone who designs and implements solutions for extracting, transforming, and visualizing data to facilitate informed decision-making.
ReplyDelete