Chapter TitleSection #. Chapter #.Page #
ALE scenario development
=
+ Creating an IDOC
+ Creating an outbound program
+ Create an inbound program
+ Setting ALE configuration
Developing your own ALE scenario
Chapter TitleSection #. Chapter #.Page #
Scenario analysis
• How does the IDOC look like ?
• How is data being sent ?
• How is the data being received ?
Chapter TitleSection #. Chapter #.Page #
IDOC creation
Chapter TitleSection #. Chapter #.Page #
IDOC creation
• Create new segments
• Create new IDOCs
• Create a new message type
• Link message type with IDOC type
Chapter TitleSection #. Chapter #.Page #
Create New Segments
Chapter TitleSection #. Chapter #.Page #
How to create Segments
Chapter TitleSection #. Chapter #.Page #
Create IDOC type
Chapter TitleSection #. Chapter #.Page #
How to create IDOC types
Chapter TitleSection #. Chapter #.Page #
Create new message type
Chapter TitleSection #. Chapter #.Page #
Link message type with IDOC type
Chapter TitleSection #. Chapter #.Page #
Outbound program development
Chapter TitleSection #. Chapter #.Page #
Outbound program
• Program logic– “How is the IDOC being IDOC created ?”
• Triggering– “How is the IDOC creation kicked off ?”
Chapter TitleSection #. Chapter #.Page #
Program logic
IDOC program
ALE layer
• Select data from application tables• Fill data into IDOC • Pass IDOC to ALE layer
(Call function MASTER_IDOC_DISTRIBUTE)• Commit Work
MASTER_IDOC_DISTRIBUTE
• Receiver determination• Segment filtering• Version Control• Dispatch Control
Slide Idea !
Chapter TitleSection #. Chapter #.Page #
MASTER_IDOC_DISTRIBUTE
Call function ‘MASTER_IDOC_DISTRIBUTE’
? Exporting
?master_idoc_control: IDOC control record
? Tables
?communication_idoc_control: returned information about the distribution
?master_idoc_data: IDOC data segments
Chapter TitleSection #. Chapter #.Page #
Control Record information
• Control record contains general information about the IDOC (“Envelope”)
• Control record is field string with structure EDIDC
• Relevant fields:?MESTYP: Logical message type
?IDOCTP: Basic IDOC type
Chapter TitleSection #. Chapter #.Page #
Data Record information
• Data records contain the data of the message
• Data records are passed as an internal table with structure EDIDD
• Relevant fields:?SEGNAM: Segment type of the specific IDOC data
record
?SDATA: 1000 byte-long character field for the data of the specific IDOC data record
Chapter TitleSection #. Chapter #.Page #
Filling an EDIDD structure
Header (55bytes) SDATA (1000bytes)…. SEGNAM ….EDIDD
Z1SEGField1 Field2 Field3 Field4
“10” “ABC”
MOVE “Z1SEG” to EDIDD-SEGNAMMOVE “10” to Z1SEG-FIELD1MOVE “ABC” to Z1SEG-FIELD2MOVE Z1SEG to EDIDD-SDATA
Slide Idea
Chapter TitleSection #. Chapter #.Page #
General Programming rules
? Design Guidelines for creating IDOC data records:
• Left-justified filing of IDOC Fields
• Replacing SAP codes with ISO codes
?currency keys
?country keys
?unit of measure
?shipping instructions
• Converting Currency Amounts
Chapter TitleSection #. Chapter #.Page #
Left-justified Filling
? All fields must be left-justified
? Character fields:
?automatic
? Non-character fields:
?‘Condense’ statement must be used
?Check IDOC documentation to find out which fields require a ‘condense’
?All types unequal to ‘char’, ‘cuky’, ‘clnt’, ‘accp’, ‘numc’, ‘dats’, ‘tims’ or ‘unit’ require a condense
Chapter TitleSection #. Chapter #.Page #
Code Conversions? Replacing SAP codes with ISO codes
– Currency keys: ‘currency_code_sap_to_iso’– Country keys: ‘country_code_sap_to_iso’– Units of measure: ‘unit_of_measure_sap_to_iso’– Shipping instructions: sap_iso_package_type_code’
• Conversion of currency amounts– ‘currency_amount_sap_to_iso’
Chapter TitleSection #. Chapter #.Page #
Code Example? MASTER_IDOC_CREATE_XAMPLE
Chapter TitleSection #. Chapter #.Page #
Exercise 2? Write outbound program
? Maintain Distribution Model
Chapter TitleSection #. Chapter #.Page #
TriggeringSlide IDea
IDOC program
ALE layer
?
MASTER_IDOC_DISTRIBUTE
• Select Data• Fill IDOC• Call MASTER_IDOC_DISTRIBUTE
Chapter TitleSection #. Chapter #.Page #
Triggering Options
• Transaction Data:
– IDOC created when application document is created– 2 Options:
• “Hardcoded call” to ALE layer• Message Control triggers call to ALE layer
• Master Data:– IDOC not imediately created– 2 Options:
• “stand-alone” program to create IDOC • Change-pointer based trigger
Chapter TitleSection #. Chapter #.Page #
“Hardcoded”-ALE-layer call
Application Posting
• Post Application document
• Need to create IDOC
• If yes • Create IDOC• Call ALE layer
• Commit Work
Customer DistributionModel
ALE layer
(Optional)
Chapter TitleSection #. Chapter #.Page #
Example
Chapter TitleSection #. Chapter #.Page #
Output Determination
ALE layer
Customer DistributionModel
Application Posting
• Post Application document
• Determine Output
• Commit Work
Output Determination
• If Output ALE (RSNASTED / ALE_PROCESSING)
• Get Process Code• Call IDOC module• Call ALE layer
IDOC moduleIDOC_OUTPUT_<MSGTYPE>• Read application data• Fill IDOC
Chapter TitleSection #. Chapter #.Page #
IDOC module? IDOC program has to be implemented as function
module
? Naming Convention: IDOC_OUTPUT_<msgtype>
? Function module gets ‘object key’ passed from message control. The object key is the primary key to the application object (I.e. Order number)
? Function module logic:
? Read application document using object key
? Fill IDOC structure
Chapter TitleSection #. Chapter #.Page #
Differences? Function module doesn’t call ‘Commit Work’
? Function module doesn’t check distribution model
? Function module doesn’t call MASTER_IDOC_DISTRIBUTE
Chapter TitleSection #. Chapter #.Page #
ALE configuration? Output determination
? Medium: ‘A’ (ALE)
? Receiver defined in Condition record is converted to receiver defined in distribution model (by ALE layer)
? ‘Publish’ the new function module
? Define Outbound Process Code
? Link Process Code to Function module
? Refer to Process Code in Partner Profile definiton(message control section)
Chapter TitleSection #. Chapter #.Page #
Example
Chapter TitleSection #. Chapter #.Page #
Change Pointers
Application Posting
• Post Application document
• Create Change Document
• Are changes ALE relevant ?
•Write Change Pointers
• Commit Work
ALE configuration
• ALE relevant Fields
Batch Program(RBDMIDOC)
IDOC Module(Masteridoc_Create_SMD_<MSGTYPE>)
• Read Change Pointers• Fill IDOC• Call ALE layer• Update Change Pointer
Master data
Change pointers
ALE layerMaster_IDOC_DISTRIBUTE
• Determine IDOC module• Call IDOC module
Chapter TitleSection #. Chapter #.Page #
IDOC module? IDOC module has to be implemented as function
module
? Naming Convention: MASTERIDOC_CREATE_SMD_<msgtype>
? Function module reads change pointers information to get data that needs to go into IDOC
? Function module logic:
? Read change pointers
? Fill IDOC structure
? Call ALE layer
? Update Change Pointer status
? Commit Work
Chapter TitleSection #. Chapter #.Page #
ALE Configuration• Define change pointer creation
• Define which change document fields are to be logged
• Change pointer activation
• Activate generally
• Activate per message type
• “Publish” new function module• Link message type to function module
Chapter TitleSection #. Chapter #.Page #
“Standalone”-Program
• Example: RBDSEMAT
• Similar to our exercise
Chapter TitleSection #. Chapter #.Page #
Which trigger ?
Only send objects that have
changed ?
Change Pointeravailable?
Masterdata ?
Standalone with custom logic to keeptrack of changes
Change Pointerbased Program
y
N
Y
Standalone programwith user-definable selection criteria
N
Y
Chapter TitleSection #. Chapter #.Page #
Which trigger ?
Ensure trans-actionalIntegrity?
Output Determination available ?
TransactionData ?
hardcoded ALElayerModification
Output determinatonbased Program
y
N
Y
N
Y
User-Exitavailable?
N
Hardcoded ALE layerno Modification
Y
See Master data
Chapter TitleSection #. Chapter #.Page #
Inbound program development
Chapter TitleSection #. Chapter #.Page #
? ALE inbound components
? Inbound function module
? ALE customizing
? Workflow task
Overview
Chapter TitleSection #. Chapter #.Page #
Overview
INBOUND_IDOC_PROCESSIDOC
ALE layer
IDOC_INPUT_<MSGTYPE>
• Read IDOC data• Post Application data• Send Success info back to ALE layer
ALE configuration• Partner Profiles• Process Code• Function module attribute• Function module registry
Workflow Task
Call function
Return Variables
If ERROR, trigger
• Version change• Segment filter• Field conversion
Chapter TitleSection #. Chapter #.Page #
? Name: Z_IDOC_INPUT_<Msgtype>
? Interface:
? Import
?Input_Method process in dialog or not?
?Mass_Processing used for WF programming
? Export
?In_Update_Task Was update ‘in update task’ used ?
?Call_Transaction_done Was a Call Transaction used ?
?Workflow_Result Workflow events for errors ?
?Application_Variable Workflow parameter
Inbound Function module
Chapter TitleSection #. Chapter #.Page #
? Interface:
? Tables
?Idoc_Contrl one entry for each IDOC control record
?Idoc_Data one entry for each IDOC data segment
? Docnum IDOC number
? Segnam Segment name
? Sdata Segment data
?Idoc_Status Status of the IDOC
?Return_Variables created/changed application objects
?Serialization_Info used for serialization check
? Exceptions
?Wrong_Function_called
Function module
Chapter TitleSection #. Chapter #.Page #
? Naming: Z_IDOC_INPUT_<Msgtype>
? Logic:
? Check, if IDOC contains the correct message type; if not raise exception WRONG_FUNCTION_MODULE_CALLED
? Initialize any global variables/tables.
? Convert the character data in table IDOC_DATA to internal format in internal tables:
?character -> numbers
?ISO codes -> SAP codes
? Check data
?If O.k., post data
?If Not: return error message to ALE
? No Commit Work !
Function module
Chapter TitleSection #. Chapter #.Page #
? Return variables for successfully processed IDOCs:
? Workflow_Result: ‘0’
? Idoc_Status: 1 record with following fields
?Docnum IDOC number
?Status ‘53’
? Return_Variables: table must contain following entries:
Entry Wf_param Doc_number
1 ‘Processed IDoc’ Idoc number
2 ‘Appl_Objects’ Appl.Object number
Return variables - success
Chapter TitleSection #. Chapter #.Page #
? Return variables for unsuccessfully processed IDOCs:
? Workflow_Result: ‘99999’
? Idoc_Status: 1 record with following fields
?Docnum IDOC number
?Status ‘51’
?Msgid, Msgno filled with the error messages ID number..
? Return_Variables: table must contain following entries:
Entry Wf_param Doc_number
1 ‘Error_IDOCs’ Idoc number
Return variables - error
Chapter TitleSection #. Chapter #.Page #
? Example: IDOC_INPUT_XAMPLE
Code example
Chapter TitleSection #. Chapter #.Page #
ALE configuration
Chapter TitleSection #. Chapter #.Page #
? Overview
IDoc controlrecord
IDoc typeSend. partnr typeSender partner no.Message typeMessage variantMessage functionTest flag
Sender typeSender no.Message typeMessage var.Message func.Fest flag
Process codeProcess typeError eventsAppl.obj.typeInbound func. Inbound func.
Input typeDialog?
Appl. obj. typeInbound func.
Message typeMessage var.Message func.
IDoc type
PartnerProfileinbound
Process codetables(inbound)
Functionmodule'sattributes
ALE functionmoduleregistry
Process code
ALE inbound configuration
Chapter TitleSection #. Chapter #.Page #
Function module registry
Chapter TitleSection #. Chapter #.Page #
Function module attributes
Chapter TitleSection #. Chapter #.Page #
Process Code
Chapter TitleSection #. Chapter #.Page #
Partner Profile
Chapter TitleSection #. Chapter #.Page #
Workflow
Chapter TitleSection #. Chapter #.Page #
ALE error handling
User action R/3 action
Execute Workitem
Fix error and reprocess IDocorFlag IDoc for deletion
Error in inbound function module
ALE triggers error event
Workitem appears in user's Inbox
Display IDoc for user processing(IDoc method "InputForeground")
ALE triggers end event
Workitem completed
input Error Occurred
input Finished
? Overview
Chapter TitleSection #. Chapter #.Page #
? Necessary Steps:
? Create new object type in Business Object Repository for IDOC; object is child of IDOCAPPL
? Create new customer task
? Create event-couplings linking
?Event ‘inputErrorOccured’ linked to standard task
?Event ‘inputFinished’ to function module
? To support mass processing:
?Create new object type as child of IDOCPACKET
? Maintain process code to refer the above objects and events
ALE error handling
Chapter TitleSection #. Chapter #.Page #
Advanced inbound topics
Chapter TitleSection #. Chapter #.Page #
• Data consistency
• Serialization
• individiual vs. mass processing
• Call transaction function modules
Issues
Chapter TitleSection #. Chapter #.Page #
Data Consistency• Problem:
– Ensure transactional integrity• Don’t process and IDOC twice• Allow for IDOC reprocessing after rollback of
application document posting
• Solution:– Application document must be posted in the same
LUW as the IDOC status records– IDOC function module must not use a ‘Commit Work’
Chapter TitleSection #. Chapter #.Page #
ALE Layer Applicationfunction module
Read IDoc(s)
Commit Work
Unlock IDoc(s) andapplication objects
Lock IDoc(s)
Write IDoc(s) statusWrite linksOptional:
Write serialization dataTrigger event(s)
Lock application objectsOptional: Serialization checkProcess IDoc dataWrite application data to DB
Data Consistency
Chapter TitleSection #. Chapter #.Page #
Receiver
1
2
1
2
Object X, changed twice:
First IDOC overtaken
Comm. LayerSender
!?!?
Input from IDOC 1 must be prevented in order not to lose information from IDOC 2
Serialization
Chapter TitleSection #. Chapter #.Page #
? Check, if IDOC has been overtaken
? Use function module ‘IDOC_SERIALIZATION_CHECK’
? react to overtaken IDOCs according to your needs
? Prerequisite is the definition of a serialization object
Serialization
Chapter TitleSection #. Chapter #.Page #
Mass Processing? Processing more than one IDOC can improve
throughput:
? more than one IDOC is processed per Commit Work
? the function can be coded to add multiple entries to a table with one update command (‘array insert’)
? Function module has to be coded in a way that it supports mass processing
? Attribute of delivered function module specifies if mass processing is supported or not
Chapter TitleSection #. Chapter #.Page #
? Pros:
? Error reprocessing in foreground
? Easy to program
? Cons:
? Call Transaction has significant performance overhead
? Automatic Commit work, no data consistency
? Recommendation:
? Try to use function modules that update database directly
? If you want to use ‘Call transaction’, they have been ‘ALE-enabled’ to guarantee data concistency
Call Transaction
Chapter TitleSection #. Chapter #.Page #
? Data Consistency:
? IDOC status record has to be update by Transaction
? Extend existing transaction to enable it for ALE
? Steps:
? 1st screen PBO module must call IDOC_INPUT_OPEN
? Before data is updated in database, transaction must call IDOC_INPUT_CLOSE
ALE-enabled transactions
Chapter TitleSection #. Chapter #.Page #
ALE layer Applicationfunction module
Transaction
Read IDoc
Lock IDocOptional: Serialization check
Process IDoc-DataFill Call Transaction tableExport IDoc no. to memory
Context1 Context 2
Commit Work
Lock application objectsProcess transaction dataWrite application data to DB
IDoc and application objectsunlocked automatically
Write IDoc statusWrite linksOptional: Write serialization data Trigger events
ALE-enabled transactions