1 PACKAGE ecx_attachment AS
2 -- $Header: ECXATCHS.pls 120.3 2005/10/30 23:18:36 susaha ship $
3 -- The name used in ecx_util.g_event to record the attachment records
4 ECX_UTIL_EVENT_ATTACHMENT CONSTANT VARCHAR2(15) := 'ECX_ATTACHMENTS';
5
6 -- Attachment types with respect to FND attachment framework under
7 -- EMBEDDED mode. Currently, only EMBEDDED_LOB_DATA_TYPE is supported.
8 EMBEDDED_SHORTTEXT_DATA_TYPE CONSTANT NUMBER := 1;
9 EMBEDDED_LONGTEXT_DATA_TYPE CONSTANT NUMBER := 2;
10 EMBEDDED_LONGRAW_DATA_TYPE CONSTANT NUMBER := 4;
11 EMBEDDED_LOB_DATA_TYPE CONSTANT NUMBER := 6;
12
13
14 ---------------------------------------------------------------------
15 -- PROCEDURE NAME: deposit_blob_attachment
16 --
17 -- DESCRIPTION:
18 --
19 -- This procedure deposit OTA received attachment files into
20 -- FND_DOCUMENTS for EMBEDDED mode. It is not intended for
21 -- upper layer uses. Instead, the upper layers are responsible
22 -- to deposit attachment files by themselves. the i_main_doc_id
23 -- is used internally to associate multipe attachment files of
24 -- a same main doc (or business object).
25 --
26 -- CHANGE HISTORY:
27 --
28 ---------------------------------------------------------------------
29 PROCEDURE deposit_blob_attachment(
30 i_main_doc_id IN OUT NOCOPY NUMBER,
31 i_file_name IN VARCHAR2,
32 i_file_content_type IN VARCHAR2 DEFAULT NULL,
33 i_file_data IN BLOB,
34 i_expire_date IN DATE,
35 i_lang IN VARCHAR2,
36 i_ora_charset IN VARCHAR2,
37 i_file_format IN VARCHAR2 DEFAULT NULL,
38 x_file_id OUT NOCOPY NUMBER
39 );
40
41
42
43 ---------------------------------------------------------------------
44 -- PROCEDURE NAME: formulate_content_id
45 --
46 -- DESCRIPTION:
47 --
48 -- This procedure is called in the user codes. It formualtes a content
49 -- ID based on the provided information. The entity_name IN parameter
50 -- should not be NULL.
51 --
52 -- CHANGE HISTORY:
53 --
54 --------------------------------------------------------------------
55 PROCEDURE formulate_content_id(
56 i_file_id IN NUMBER,
57 i_entity_name IN VARCHAR2,
58 i_pk1_value IN VARCHAR2,
59 i_pk2_value IN VARCHAR2,
60 i_pk3_value IN VARCHAR2,
61 i_pk4_value IN VARCHAR2,
62 i_pk5_value IN VARCHAR2,
63 x_cid OUT NOCOPY VARCHAR2
64 );
65
66 ---------------------------------------------------------------------
67 -- PROCEDURE NAME: register_attachment
68 --
69 -- DESCRIPTION:
70 --
71 -- This procedure should be called from the Message Designer's actions
72 -- by user code. Users may first deposit an attachment using the
73 -- provided deposit_XX_attachment API. Immediately afterwards, the users
74 -- call the register_attachment API to inform/register this attachment
75 -- deposition with XML-Gateway. In the case when the users have deposited
76 -- their attachments by themselve to the appropriate attachment repository,
77 -- the user must still call this register_attachment to inform XML-Gateway.
78 -- i_cid is a user provided id to denote a given attachment. It has
79 -- significance only to the user, not to the XML-Gateway. This i_cid is
80 -- later on packaged into an outgoing MIME message as content-type MIME
81 -- header field by OTA. The i_file_id is an unique key enable retrieval
82 -- of an attachment from some repository, while the i_data_type denotes the
83 -- type (blob, short_text, long_text, or long_raw) of the attachment. The
84 -- i_file_id and i_data_type together facilitate the retrieval of an
85 -- attachment from a specific attachment repository. This register_attachment
86 -- internally package the i_cid and i_file_id into the ECX_ATTACHMENT field of
87 -- the ecx_utils.g_event. Repeated attachment depositions cause repeated
88 -- register_attachment. Ultimately, a serial of i_cid and i_file_id are
89 -- concanated and packed into the ECX_ATTACHMENT filed of ecx_utils.g_event.
90 -- Among the serial of i_cid and i_file_id, it is expected that no different
91 -- i_file_id can be associated with a same i_cid
92 --
93 -- CHANGE HISTORY:
94 --
95 PROCEDURE register_attachment(
96 i_cid IN VARCHAR2,
97 i_file_id IN NUMBER,
98 i_data_type IN NUMBER
99 );
100
101 ---------------------------------------------------------------------
102 -- PROCEDURE NAME: register_attachment
103 --
104 -- DESCRIPTION:
105 --
106 -- This procedure is called in the user codes. It register a user
107 -- deposited attachment with the XML-Gateway, so that the XML-Gateway
108 -- may later construct a MIME message to encapuslate this attachment.
109 --
110 -- CHANGE HISTORY:
111 --
112 PROCEDURE register_attachment(
113 i_entity_name IN VARCHAR2,
114 i_pk1_value IN VARCHAR2,
115 i_pk2_value IN VARCHAR2,
116 i_pk3_value IN VARCHAR2,
117 i_pk4_value IN VARCHAR2,
118 i_pk5_value IN VARCHAR2,
119 i_file_id IN NUMBER,
120 i_data_type IN NUMBER,
121 x_cid OUT NOCOPY VARCHAR2
122 );
123
124
125 ---------------------------------------------------------------------
126 -- PROCEDURE NAME: register_attachment_offline
127 --
128 -- DESCRIPTION:
129 --
130 -- This procedure is called in the user codes for BES cases. The user
131 -- register attachment maps first before raising a business event. As
132 -- part of the event, there is a generate function to produce XML
133 -- business document without attachment. Therefore, it is necessary
134 -- to call this register_attachment_offline beforehand.
135 --
136 -- CHANGE HISTORY:
137 --
138 ---------------------------------------------------------------------
139 PROCEDURE register_attachment_offline(
140 i_cid IN VARCHAR2,
141 i_file_id IN NUMBER,
142 i_data_type IN NUMBER
143 );
144
145 ---------------------------------------------------------------------
146 -- PROCEDURE NAME: register_attachment_offline
147 --
148 -- DESCRIPTION:
149 --
150 -- This procedure is called in the user codes for BES cases. The user
151 -- register attachment maps first before raising a business event. As
152 -- part of the event, there is a generate function to produce XML
153 -- business document without attachment. Therefore, it is necessary
154 -- to call this register_attachment_offline beforehand. This procedure
155 -- differs from the other register_attachment_offline in that its
156 -- parameters are different. It does not pre-construct an unique
157 -- CID before calling.
158 --
159 -- CHANGE HISTORY:
160 --
161 ---------------------------------------------------------------------
162 PROCEDURE register_attachment_offline(
163 i_entity_name IN VARCHAR2,
164 i_pk1_value IN VARCHAR2,
165 i_pk2_value IN VARCHAR2,
166 i_pk3_value IN VARCHAR2,
167 i_pk4_value IN VARCHAR2,
168 i_pk5_value IN VARCHAR2,
169 i_file_id IN NUMBER,
170 i_data_type IN NUMBER,
171 x_cid OUT NOCOPY VARCHAR2
172 );
173
174
175 ---------------------------------------------------------------------
176 -- PROCEDURE NAME: remove_attachmentMaps_offline
177 --
178 -- DESCRIPTION:
179 --
180 -- This procedure is called in the user codes for BES cases. The user
181 -- register attachment maps offline first, it then use this
182 -- remove_attachmentMaps_offline to retrieve and remove the entire
183 -- attachment mapping string before putting it as part of the
184 -- event parameters using wf_event.AddParameterToList function.
185 -- Note, this method remove the existing maps as well.
186 --
187 -- CHANGE HISTORY:
188 --
189 ---------------------------------------------------------------------
190 PROCEDURE remove_attachmentMaps_offline(
191 x_attachment_maps OUT NOCOPY VARCHAR2);
192
193 ---------------------------------------------------------------------
194 -- PROCEDURE NAME: map_attachments
195 --
196 -- DESCRIPTION:
197 --
198 -- This procedure is called by the Message Designer ECX_OUTBOUND right
199 -- after it enqueues the outgoing business document in outbound AQ. This
200 -- procedure is responsible to maintain mappings between the main business
201 -- document and its attachments.
202 --
203 -- CHANGE HISTORY:
204 --
205 ---------------------------------------------------------------------
206 PROCEDURE map_attachments(
207 i_msgid IN RAW
208 );
209
210 ---------------------------------------------------------------------
211 -- PROCEDURE NAME: map_attachments
212 --
213 -- DESCRIPTION:
214 --
215 -- This procedure is called after the XML doc is enqueues to
216 -- outbound AQ. This procedure is responsible to maintain mappings
217 -- between the main business document and its attachments based
218 -- based on information stored in the event
219 --
220 -- CHANGE HISTORY:
221 --
222 ---------------------------------------------------------------------
223 PROCEDURE map_attachments(
224 i_event IN WF_EVENT_T,
225 i_msgid IN RAW
226 );
227
228 ---------------------------------------------------------------------
229 -- PROCEDURE NAME: remap_attachments
230 --
231 -- DESCRIPTION:
232 --
233 -- This procedure is called by ECX_INBOUND_TRIG for the passthrough
234 -- cases. Basically, the XML-Gateway inbound processing layer is
235 -- responsible to maintain attachment mapping information for
236 -- passthrough business documents. The i_msgid IN parameter
237 -- is the AQ message ID for the passthrough business document once
238 -- it is pushed into the ECX_OUTQUEUE after all the passthrough
239 -- processing has been completed.
240 --
241 -- CHANGE HISTORY:
242 --
243 ---------------------------------------------------------------------
244 PROCEDURE remap_attachments(
245 i_msgid IN RAW
246 );
247
248
249 ---------------------------------------------------------------------
250 -- PROCEDURE NAME: retrieve_attachment
251 --
252 -- DESCRIPTION:
253 --
254 -- This procedure is responsible to retrieve an attachment based on
255 -- provided msgId and cId. It can be used in two places. First, the
256 -- OTA java layer uses this procedure to retrieve attachments and
257 -- formulates outbound MIME messages. Second, the inbound portion
258 -- (receiving side) of the Message Designer uses this procedure to
259 -- retrieve attachments. In the second case, the msgId must be the
260 -- original enqueue msgId the OTA obtains when it deposites
261 -- received MIME attachment parts on inbound side.
262 --
263 -- CHANGE HISTORY:
264 --
265 ---------------------------------------------------------------------
266 PROCEDURE retrieve_attachment(
267 i_msgid IN RAW,
268 i_cid IN VARCHAR2,
269 x_file_name OUT NOCOPY VARCHAR2,
270 x_file_content_type OUT NOCOPY VARCHAR2,
271 x_file_data OUT NOCOPY BLOB,
272 x_ora_charset OUT NOCOPY VARCHAR2,
273 x_file_format OUT NOCOPY VARCHAR2
274 );
275
276
277 ---------------------------------------------------------------------
278 -- PROCEDURE NAME: retrieve_attachment
279 --
280 -- DESCRIPTION:
281 --
282 -- This procedure is responsible to retrieve an attachment based on
283 -- provided msgId and cId. It can be used in two places. First, the
284 -- OTA java layer uses this procedure to retrieve attachments and
285 -- formulates outbound MIME messages. Second, the inbound portion
286 -- (receiving side) of the Message Designer uses this procedure to
287 -- retrieve attachments. In the second case, the msgId must be the
288 -- original enqueue msgId the OTA obtains when it deposites
289 -- received MIME attachment parts on inbound side. This API differs
290 -- from the previous retrieve_attachment API in that it returns
291 -- language as well. The language is useful to transmitted across
292 -- the wire to destination sides. This new retrieve_attachment is
293 -- created, so that existing code dependent on the previous
294 -- retrieve_attachment will not break.
295 --
296 -- CHANGE HISTORY:
297 --
298 ---------------------------------------------------------------------
299 PROCEDURE retrieve_attachment(
300 i_msgid IN RAW,
301 i_cid IN VARCHAR2,
302 x_file_name OUT NOCOPY VARCHAR2,
303 x_file_content_type OUT NOCOPY VARCHAR2,
304 x_file_data OUT NOCOPY BLOB,
305 x_language OUT NOCOPY VARCHAR2,
306 x_ora_charset OUT NOCOPY VARCHAR2,
307 x_file_format OUT NOCOPY VARCHAR2
308 );
309
310 ---------------------------------------------------------------------
311 -- PROCEDURE NAME: retrieve_attachment
312 --
313 -- DESCRIPTION:
314 --
315 -- This procedure is responsible to retrieve an attachment based on
316 -- provided fileId and dataType. It can be used in one places. The
317 -- WS java layer uses this procedure to retrieve attachments and
318 -- formulates outbound MIME messages. This API differs
319 -- from the previous retrieve_attachment API in that it returns
323 -- so that existing code dependent on the previous
320 -- language and it takes fileId and dataType as inputs. The language
321 -- is useful to transmitted across the wire to destination sides.
322 -- This new retrieve_attachment is created for the WS,
324 -- retrieve_attachment will not break.
325 --
326 -- CHANGE HISTORY:
327 --
328 ---------------------------------------------------------------------
329 PROCEDURE retrieve_attachment(
330 i_file_id IN NUMBER,
331 i_data_type IN NUMBER,
332 x_file_name OUT NOCOPY VARCHAR2,
333 x_file_content_type OUT NOCOPY VARCHAR2,
334 x_file_data OUT NOCOPY BLOB,
335 x_language OUT NOCOPY VARCHAR2,
336 x_ora_charset OUT NOCOPY VARCHAR2,
337 x_file_format OUT NOCOPY VARCHAR2
338 );
339
340
341 ---------------------------------------------------------------------
342 -- PROCEDURE NAME: reconfig_attachment
343 --
344 -- DESCRIPTION:
345 --
346 -- This procedure is called by user code. They may repeatedly retrieve
347 -- their attachment contents by calling retrieve_attachment first. Subseqeuntly,
348 -- if they choose to reconfig their attachments by resetting appropriate
349 -- mapping vakues in the fnd_attached_documents table, they may use this
350 -- reconfig_attachment procedure. On the other hand, the users may skip this
351 -- procedure call, and instead just save the retrieve BLOB (attachment contents)
352 -- by themselves.
353 --
354 -- CHANGE HISTORY:
355 --
356 ---------------------------------------------------------------------
357 PROCEDURE reconfig_attachment(
358 i_msgid IN RAW,
359 i_cid IN VARCHAR2,
360 i_entity_name IN VARCHAR2,
361 i_pk1_value IN VARCHAR2,
362 i_pk2_value IN VARCHAR2,
363 i_pk3_value IN VARCHAR2,
364 i_pk4_value IN VARCHAR2,
365 i_pk5_value IN VARCHAR2,
366 i_program_app_id IN NUMBER,
367 i_program_id IN NUMBER,
368 i_request_id IN NUMBER,
369 x_document_id OUT NOCOPY NUMBER
370 );
371
372 END ecx_attachment;
[Home] [Help]