I am creating an EBS using a custom EBO. I am using a request delayed response message exchange pattern. I have designed the EBM’s so they match EBM’s that are provided by AIA for other EBO’s.
I have two message types, CreateAccessEBM and CreateAccessResponseEBM.
The structure of the CreateAccessResponseEBM Message (in AccessEBM.xsd) is as follows:
CreateAccessResponseEBM Element is of type CreateAccessResponseEBMType
CreateAccessResponseEBMType has two items; corecom:CreateResponse of type CreateResponseType and CreateAccessResponse of type CreateAccessResponseType
CreateAccessResponseType extends AccessEBMType and is an instance of the EBO.
I copied this structure exactly from another AIA Provided EBO.
When the object is created there needs to be some other creation data returned alongside the response EBO. E.g. user who created the access, etc. These can’t be part of the EBO as they are specific to the message.
1. My question is where should these elements be added
2. Where is this documented
I can’t find any reference to this in the AIA documentation at all.
Normally these kind of elements should be part of a common xsd file within AIA. Please first check if this element is not already part of the common xsd file within AIA.
If not and you really want to keep the same logic then you can create a separate custom common xsd file to include the creation date element. This common file can be present in the same directory structure as your custom EBO.
The question is do you really want to create a separate common schema for just one element that you are using for a custom developed service anyway?
If it was me I would just include this element as part of your custom EBO.
Having the element as part of the EBO is an option. Although it dosen't make sense logically.
The EBO is uesd for
The since the EBO is shared, adding the elements here will mean adding them to all the messages.
The element might be relevant in the CreateAccessResponse message but it would not be relevant for the QueryAccessResponse message.
One option I thought of would be to add the desired fields to CreateAccessResponseType. This would result in the fields being only in the response message. It also only involves altering AccessEBM.xsd which is my custom EBM; but what if I needed these fields for a standard EBO?
In your answer you talk about common xsd files. Can you let me know which common xsd file you are refering to and which element/type in that file? I can see a create response type which could be a logical place but it does not show any elements in this type.
I have traced this to AIAMetaData\AIAComponents\EnterpriseObjectLibrary\Core\Common\V1\meta.xsd
This has two elements in it but these are not shown in JDeveloper when I view the EBM - I can't understand why.
There is a ResponseNotification which has ResponseNotificationType which has ElementPath, Value, StatusCode and Message.
These could be where I should put the data I need but again the elements don't get displayed.
I am trying to use the AIA schema as properly as I possibly can but in order to do this I need more information. I have had a look in meta.html but this doesn't refer to ResponseNotificationType.
The documentation doesn’t shed light on this. I am trying to resist the urge to simply add my own elements to the schema but as I can't find any documentation explaining the proper use of the schema this is getting increasingly difficult.
What is needed are detailed examples of each type of message and where particular types of data should be stored in the AIA structure. Without this I have no way of knowing if I am using or mis-using the AIA structure.
I would avoid updating existing out of the box EBOs. These EBOs are related to the AIA version you are using. Any upgrades later will remove your additional elements. In theory as the customer is buying an out of the box integration there shouldn't be many changes. Otherwise you don't get the full benefits that AIA promises.
The idea behind AIA is to create a canonical data model of one single view of the data that is used commonly across your service enterprise. This means any type you create should be according to this philosophy even when you create your own custom elements. Be aware not to create any duplicated types!
The common schema is indeed the schema in the directory you mentioned \AIAComponents\EnterpriseObjectLibrary\Core\Common\V1\
The extra elements you mentioned are well suited to be part of the meta.xsd schema. The suggestion to add these are part of the responseNotificationType sounds good. However I would not touch this and instead add the elements you need directly under the CreateResponse type. I would not update this directly in the meta.xsd schema for the reasons mentioned earlier. Instead I would overwrite the CreateResponse type in your own custom schema. This means you are still using the out of the box structure, but with the flexibility of adding your own custom elements if required (should be more exception than rule).
How can you achieve this?
First identify any current custom schema to overwrite the existing type. This could be your existing EBO. There is no good or wrong as long you keep the philosophy of AIA in mind. I would in your scenario create a custom meta.xsd schema similar as the one used by the out of the box version. You import the existing out of the box meta.xsd schema. Then specify your own CreateResponse type. I have developed a quick example see below:
Notice that the extra custom element included is userCreated. Of course if you don't need RequestEBMID or ResponseNotification you can leave this out.
<?xml version="1.0" encoding="UTF-8"?>
<import namespace="http://xmlns.oracle.com/EnterpriseObjects/Core/Common/V1" schemaLocation="meta.xsd"/>
<element name="input" type="string"/>
<element name="result" type="string"/>
<element name="CreateResponse" type="bpe:CreateResponseType"/>
<element name="RequestEBMID" type="met:IdentifierType" minOccurs="0"/>
<element ref="met:ResponseNotification" minOccurs="0" maxOccurs="unbounded"/>
<element name="userCreated" type="string"/>