Table of Contents
How do cards work with collectors?
Finalizing the logical port configuration
Finalizing the logical port configuration
Finalizing the logical port configuration
Integration of customer workflows
Following you will find the list of systems integrations we already offer.
Please note that we are faster in integrating systems than documenting. If you don't find the details you are looking for, feel free to contact us.
List of standard integrations:
- REST Webservices
- Sitrion Social
- Microsoft SQL
- Microsoft SharePoint
- Microsoft Office365
- SAP RFC
- SAP NW Gateway
- SAP HCM
- SAP ERP
- K2
List of custom integrations:
- Microsoft Exchange
- Microsoft Dynamics
- Microsoft PowerApps
- SAP Hana Cloud Platform
- Concur
- Ariba (on-premises)
- Peoplesoft
- Salesforce
Collectors are a mechanism to move data from backend systems into the ONE Cloud to ensure that the clients can quickly retrieve and render Cards. Each Collector is optimized to work with a specific backend system and simply integrates with the ONE Cloud at the point of passing data into the Card API along with the identity of the associated card implementation.
How do cards work with collectors?
|
|
|
|
|
|
General
Card Screens
Detail screenComponents: Cards have always two components. The metadata from the Collector for a given backend system and the Card UI based on an AppBuilder Card project. If cards are using actions, usually a third component is included, the Connector to the given backend system.
Collector
A Collector is a piece of software which usually gets installed in the backend system (e.g. SharePoint or SAP) or at some place from where it can connect with the backend.
Metadata
Metadata is the data which is already in a well formed format, which can be consumed by the ONE cloud.
Sample Metdata (JSON format):
Card Project
The AppBuilder Card Project is the UI and translation layer of a Card
UI
The UI defines the look and feel of the card screens (summary and detail).
Translation
The translation of the incoming metadata is performed in the code-behind in a “TranslateCard” method. This also allows to manipulate data, enable push notifications and more.
Screen designer
Translation of metadata to screen fields (Definition of header information, Push notification, …)
Mapping of metadata fields to screen fields
Actions
Today Cards can have two different kind of actions a single action (“Button”) and a “ConfirmAction”. A single action directly executes an assigned action and a confirm action provides upfront an entry field for a simple string/text.
Connector
Actions are usually connecting back to a backend system like on approvals back to SharePoint or SAP. Therefore the ONE connectors can be used to define certain actions
Action Bar on a mobile device
This diagram should give a high level overview of the overall card dataflow
The Sitrion ONE SAP workflow collector is a SAP program to send workflow decision steps out of SAP to the web service ONE hub. The collector core is designed to be run on all SAP System and not related to any SAP module specific functionality. In standard shipment, the collector does not contain any workflow task specific coding, the data evaluation will be the same for all task types.
Requirements
- SAP ECC 6.0 EHP 4 at minimum
- Standard SAP workflow customization (transaction SWU3)
- Implemented and activated workflow(s) with "User Decision Step"
- Import of the ONE SAP collector transport (transport of copies) with objects in Sitrion's own /APPS/ namespace
- Initial Configuration
- Installed Card Webservice
- (Optional) Schedule background job periodically to run our SAP Report /APPS/ONE_RUN periodically and push data into ONE
Requirements for customization
For the basic customizing your the following permissions are required:
SAP User
The SAP user is needed for configuration purposes
Customizing Authorization for Sitrion ONE collector and SOA Manager
SM30, SM31, SOAMANAGER
(Optional) Setup ONE Collector as periodically background job
SP01, SM37
By default, the ONE collector retrieves the user decision step task description without specific details. If you want to enrich the data which get's provided to the user, you need the following permissions in addition:
SAP User
The SAP user is needed for implementation and configuration purposes
SAP Developer License Key
The key is needed to integrate custom workflow decision tasks through enhancement implementation
Developer Authorization at minimum access to transactions
Debugging authorization
SE38 to test Sitrion SAP Collector and enhancement implementation
SE80 to implement the custom enhancements
SE16, SE11 for testing and analysis purposes
General workflow authorizations for evaluation and analysis purposes
SWDD, SWIA, SWI1
The initial configuration describes the major steps for a basic customizing of the SAP Collector.
The following steps are describing the easiest possible customizing to check if the collector is working properly. Instead of using the tables direclty the program /APPS/ONE_IMG can be used as well for the customizing.
- Call transaction SM31 and enter /APPS/ONE_CON_TY in input field and choose maintain to define the connection types. Type W are supported by default.
- Create the entry as shown below
- Call transaction SM31 and enter /APPS/ONE_CON_F in input field and choose maintain to define field for the connection types. The fields shown are obligatory; missing fields will lead to an exception.
- Create the entry as shown below
- Call transaction SM31 and enter /APPS/ONE_CON_FV in input field and choose maintain to define field values for the connection types. The field values shown are obligatory; missing fields will lead to an exception.
- Create the entry as shown below (adjust as needed)
If you don't have a LOG_PORT yet created, please check belows steps, where the document describes how to create a logical port
- Call transaction SM31 and enter /APPS/ONE in input field and choose maintain to define an instance.
- Create a new entry as shown below and save (change values as needed, especially Company Id and Company Password, you can find both values on the "Get started" section on one.sitrion.com)
- Call transaction SM31 and enter /APPS/ONE_DEC in input field and choose maintain
- Create new entries as shown to define the decision alternatives. (change and translate entries as needed, translations should be made for every workflow receiver language)
The entry without specifying a task ID will be used as fallback in case no proper entry is found. An error only occurs in case no entry is found and no fallback is customized.
- Call transaction SM31 and enter /APPS/ONE_USER in input field and choose maintain
- Create new entries if needed
If no entry is made, the user filter is excluded, which means, every user would get processed.
- Call transaction SM31 and enter /APPS/ONE_TASK in input field and choose maintain
- Create a new entry as shown below and save (change values as needed)
Logical Port (pre EHP6)
The following steps are showing the configuration for a logical port in SAP. This defines the connection between SAP and web services, which is built into the Hub. The logical port can be configured by using the transaction SOAMANAGER.
Helpful infomation around the SOAMANAGER can be found here:
Active Services in SICF
Configuring Web Services in SOA Manager
After executing the transaction a browser window opens and shows the following screen. Use tab Application and Scenario Communication and choose "Single Service Administration"
- Search by "ConsumerProxy"
- Search Pattern "ICardService" (case sensitive)
- Click "Go"
This should show the following entry:
Select the entry in the screen above and click "Apply Selection". The area which is shown below appears, choose the "Configurations" tab and click "Create Logical Port"
- Define a logical port name (this name is the name, which is customized in the table /APPS/ONE_CON_FV, field LOG_PORT on connection type "W")
- Enter a description of your choice
- Provide the URL to the Hub webservice. The URL will be similar to this: http://10.56.102.68:8095/CardService.svc?singleWsdl, you'll have of course to replace the IP by your IP or hostname.
Finalizing the logical port configuration
Once you applied the settings on the screen before, you just have to Save your configuration by clicking "Save". Now you've a new logical port, which you've to provide to the ONE customizing table /APPS/ONE_CON_FV, field LOG_PORT on connection type "W"
The following steps are showing the configuration for a logical port in SAP. This defines the connection between SAP and web services, which is built into the Hub. The logical port can be configured by using the transaction SOAMANAGER.
Helpful information around the SOAMANAGER can be found here:
Active Services in SICF
Configuring Web Services in SOA Manager
After executing the transaction, a browser window opens and shows the following screen. Use tab Service Administration and choose "Web Service Configuration"
- Search by "ConsumerProxy"
- Search Pattern "ICardService"
- Click "Go"
This should show the following entry:
By clicking the above found entry, you have to switch to the "Configurations" tab. and Create a new Logical Port based on "WSDL Based Configuration"
Define a logical port name (this name is the name, which is customized in the table /APPS/ONE_CON_FV, field LOG_PORT on connection type "W") and a description of your choice.
Provide the URL to the Hub webservice. The URL will be similar to this: http://mycardwebserviceserver:8095/CardService.svc?singleWsdl, you'll have of course to replace the IP by your IP or hostname.
Finalizing the logical port configuration
The following screens can just be confirmed with "Next" until you reach the "HTTPSettings" screen.
Please validate the computer name of access URL. This should be the host name or IP of the machine where the webservice is running.
Finalizing the logical port configuration
The following screens can just be confirmed with "Next" until you reach the final screen, which you can confirm with "Finish".
The collector will be started by using SAP Report /APPS/ONE_RUN. This report is designed to be run as periodical job in background but can be used as dialog report as well. It consists of two screens, the selection screen and the result screen if the option protocol was chosen.
The following selection parameters are available:
- Test - With only the 'Test' checkbox clicked the program will run and execute all SAP checks, this will allow to send the same messages repeatedly. It will not produce any output to user and simulates running in background.
- Protocol - Click only the 'Protocol' check box, this will send any SAP data found to Sitrion Cloud on a per run basis.
- "Create JSON Files" - With the 'Test' and 'Create JSON Files' checkboxes checked, the program will run the same as in having only the 'Test' checkbox but, it will produce an ALV output that will display results of the run as well as allowing the user to see the JSON files produced that were sent to the cloud. This would be used for initial development and troubleshooting.
A result screen only exists in case the selection parameter protocol was used. The protocol table shows details for every single item which was send to the ONE hub and a description in case it was not send. There is a single leading entry per instance followed by work item entries.
The description column shows possible exceptions. With a double click on an entry in this column, you can see the detailed view of it.
The JSON output column shows the JSON (if requested in the selection screen before) which gets returned from the webservice on a successful call. With a double click on an entry in this column, you can copy the full JSON to your desktop. The JSON is quite helpful for creating Cards based on the given metadata in AppBuilder.
There are two BAdI's related to the collector. The most important one is the /APPS/ONE_BADI. Since this allows you to enhace the data, which is retrieved by default from the workflow with more relevant information, which is maybe needed beside the standard workflow information. The /APPS/ONE_SEND_BADI is currently implemented in the way, that the outgoing communcation goes through a webservice call to the Hub.
/APPS/ONE_BADI
The BAdI /APPS/OS_BADI is implemented using enhancement spot /APPS/ONE_ENH_SPOT. This BAdI is used for general functions related to data retrieval. This BAdI can have multiple active implementations. To make sure the correct implementation is used the BAdI will be instantiated using a Filtervalue the value is equal to the instance name defined in customizing (customizing table /APPS/ONE). There is a fallback implementation available which will be used in case no implementation is found for the instance name. This BAdI enables the customer to influence the data determination and creation of the XML structure. The available methods are described below. The BAdI is implemented in a way that it behaves like a persistent object. Lifetime starts with DETERMINE_ITEMS and ends after PROCESS_ITEMS. So it is possible to store information in BAdI class (custom implementation) for later use in lifetime of object.
CHANGE_ITEMS
This method is implemented in method DETERMINE_ITEMS of class /APPS/CL_ONE after the standard data evaluation. The following parameters are available:
|
Name |
Type |
Description |
|
IS_CUSTOMIZING |
Importing |
contains the customizing entry for current instance |
|
IV_FROM |
Importing |
contains timestamp for begin of evaluation period for workitems |
|
IV_TO |
Importing |
contains timestamp for end of evaluation period for workitems |
|
IV_TASK |
Importing |
contains tasks which were considered for data evaluation |
|
CT_ITEMS |
Changing |
contains items which were determined |
The data determination timestamp stored in run history and used by the collecotr to evaluate items will not be changed that means a long runtime may lead to a time gap. This is in the responsibility of a custom own implementation to consider this. The easiest way is to use the delivered timeframe (IV_FROM – IV_TO) instead of the current time for additional data evaluation to make sure that items not in this frame are considered at next runtime.
CHANGE_USERDETAILS
This method is implemented in method is implemented in method GET_USER_DETAILS of class /APPS/CL_ONE and will be called for each work item and its evaluated receivers.
|
Name |
Type |
Description |
|
IS_CUSTOMIZING |
Importing |
contains the customizing entry for current instance |
|
IS_WI_HEAD |
Importing |
contains work item head data the user information are related to |
|
CT_USERDETAILS |
Changing |
Contains the information for each user related to current workitem |
It can be used to change, delete or add information. In case the mail address for user is not stored in user detail data the method can be used to add this information as it is needed for sending the notification. Another example is the language. At the moment only the mail address and the language (field langu_p and langup_iso in user details) are used.
CHANGE_DATA
This method is implemented in method PROCESS_ITEM of class /APPS/CL_ONE_SYNC. It is called after the evaluation of receivers and the basic data. The following parameters are available:
|
Name |
Type |
Description |
|
IS_CUSTOMIZING |
Importing |
contains the customizing entry for current instance |
|
IS_WI_HEAD |
Importing |
contains work item head data the notifications are based on |
|
CT_NOTIF |
Changing |
contains the determined notifications to be send |
This method will be called once for each WI determined. Remember that the BAdI class is “persistent” so it is possible to store data if a custom own implementation is created to minimize evaluation effort. The data is still available on next call as long it happens in the same run of instance.
CREATE_XML
This method is implemented in method PROCESS_ITEM after data determination and is responsible for XML creation. The program itself does not contain a XML conversion. The standard fallback class contains an implementation which can be copied in case a custom own implementation is used. Without copying no XML is created.
|
Name |
Type |
Description |
|
IT_DATA |
Importing |
Contains the evaluated data |
|
RV_XML |
Returning |
Contains the data as XML rawstring |
The XML will be created by using the transformation XSLT /APPS/ONE_DATA.
/APPS/ONE_SEND_BADI
BAdI /APPS/ONE_SEND_BADI is implemented using enhancement spot /APPS/ONE_ENH_SEND_SPOT. This BAdI enables the customer to influence how the data is send. In standard the information is send by mail. The BAdI will be instantiated by using a filter. This Filter is the value of the related connection type (defined in /APPS/ONE_CON_TY and related to an instance by /APPS/ONE). Currently only W (Web Service) is supported. There is no fallback available. The BAdI is implemented in a way that it behaves like a persistent object. Lifetime starts with at the beginning of PROCESS_ITEMS and ends at the end of PROCESS_ITEMS. So it will be possible to store information in BAdI class for multiple uses in lifetime of the object. This BAdI can have more than one active implementation so it is possible to send the gathered information to more than one system or in more than one way. As the customizing is not designed to consider this and the order of execution of each is unknown the history data for work items may contain invalid data and may affect the run history information as well. It is in the responsibility of custom implementation to take care of this.
SEND_MESSAGE
|
Name |
Type |
Description |
|
IS_CUSTOMIZING |
Importing |
contains the customizing entry for current instance |
|
IS_CONNECTION |
Importing |
contains the customizing entry for connection information related to current instance |
|
IS_WI_HEAD |
Importing |
contains work item head data the notifications are based on |
|
IV_TEST |
Importing |
A flag indicating if program runs in test mode |
|
IV_SENDER |
Importing |
Contains the name of the user which is used for sending the data mail |
|
CS_XML |
Changing |
Contains content and information, in standard the time stamp for sending is changed and the success flag will be erased in case an error occurs |
Next to report described in the usage section, the core functionality is located in class /APPS/CL_ONE. It contains the following methods and attributes:
|
Method Name |
Description |
|
CONSTRUCTOR |
Initiates an object and reads values from customizing which are needed for data evaluation |
|
DETERMINE_ITEMS |
Determines the set of relevant work items to be processed |
|
CREATE_TIME_STAMP |
Returns a time stamp |
|
PROCESS_ITEMS |
Processes all items, there is no import parameter for items as they are stored local by DETERMINE_ITEMS |
|
SEND_MAIL |
Sends a mail, data is defined by import parameters |
|
SET_RUN_INFORMATION |
Sets runtime information about the current instance to table /APPS/ONE_RUN; needs to be called for every instance |
|
GET_WI_ITEMS |
Returns information about the processed items; can be used for protocol purposes |
|
GET_RUN_INFO |
Returns runtime information about the current instance |
|
SET_ELEMENT |
Adds information to the local element table, this table is used to build the XML |
|
PROCESS_ITEM |
Process a single work item and returns basic runtime data |
|
GET_WI_DETAILS |
Returns detail data for a work item |
|
GET_RECEIVERS |
Returns the receivers and their user details for a work item |
|
GET_CREATOR |
Returns the creator and its user details for a work item |
|
GET_USER_DETAILS |
Returns user details for a user |
|
GET_TEXTS |
Returns text related to a work item (decision information and work item description text) |
|
SET_DATA |
Sets the determined detail data to a local table |
|
SET_PROCESS_INFORMATION |
Set information about processed work items to database table /APPS/ONE_WI |
|
GET_DEFAULT_LANGUAGE |
Returns system default language |
|
GET_INSTALLED_LANGUAGE |
Returns list of languages installed in the current system |
In general the public methods DETERMINE_ITEMS and PROCESS_ITEMS are covering all needed information. SET_RUN_INFORMATION and SET_PROCESS_INFORMATION should be used too to ensure proper data evaluation. GET_WI_ITEMS and GET_RUN_INFO can be used to get information about each single item and general execution information. See report /APPS/ONE_RUN for example.
There are several other objects and setting which will be described high level below. There may be dependent elements not described here:
|
Name |
Type |
Description |
|
/APPS/CL_ONE |
Class |
Main class |
|
/APPS/CX_ONE |
Class |
Exception class |
|
/APPS/ONE_CL_BADI_FB |
Class |
Fallback class for badi implementation |
|
/APPS/ONE_CL_SEND_BADI_FB |
Class |
Fallback class for badi implementation |
|
/APPS/ONE |
Package |
Package for development |
|
/APPS/DTONE_SBAL_TEXT_01 |
Documentation |
Text used in exception classe |
|
/APPS/ONE_DO_CON_TYPE |
Domain |
Connection type |
|
/APPS/ONE_DO_DECISION_TYPE |
Domain |
Decistion type |
|
/APPS/ONE_DO_MAX_RETRY |
Domain |
Max retry count |
|
/APPS/ONE_DO_SEQNR |
Domain |
Sequence number |
|
/APPS/ONE_DO_WI_DESCRIPTION |
Domain |
Work item description text |
|
/APPS/ONE_DO_WI_STATUS |
Domain |
Work item status |
|
/APPS/SU_DO_DECISION_NUMBER |
Domain |
Decision ID |
|
/APPS/ONE_DS_ATT_NAME |
Data Element |
Attachment name of data attachment |
|
/APPS/ONE_DS_ATT_TYPE |
Data Element |
Attachment type of data attachment |
|
/APPS/ONE_DT_ACTIVE |
Data Element |
Active flag |
|
/APPS/ONE_DT_CON_SUBJECT |
Data Element |
Subject of mail |
|
/APPS/ONE_DT_CON_TYPE |
Data Element |
Type of connection |
|
/APPS/ONE_DT_DECISION_NUMBER |
Data Element |
Decision ID |
|
/APPS/ONE_DT_DECISION_TEXT |
Data Element |
Decision text |
|
/APPS/ONE_DT_DECISION_TYPE |
Data Element |
Decision Type |
|
/APPS/ONE_DT_DESCR_FLAG |
Data Element |
Description flag |
|
/APPS/ONE_DT_INCL_SUBST |
Data Element |
Substitutes flag |
|
/APPS/ONE_DT_INSTANCE_NAME |
Data Element |
Instance name |
|
/APPS/ONE_DT_MAX_RETRY |
Data Element |
Max retry count |
|
/APPS/ONE_DT_NEW_ONLY |
Data Element |
Only new items flag |
|
/APPS/ONE_DT_OVERWRITE |
Data Element |
Overwrite flag |
|
/APPS/ONE_DT_SEQNR |
Data Element |
Sequence number |
|
/APPS/ONE_DT_WI_DESCRIPTION |
Data Element |
Work item description text |
|
/APPS/ONE_DT_WI_STATUS |
Data Element |
Work item status |
|
/APPS/ONE_DT_WORKFLOW_ID |
Data Element |
Workflow ID |
|
/APPS/ONE_DT_WORKITEM_DESC |
Data Element |
Work item description |
|
/APPS/ONE_DT_START_DATE |
Data Element |
Start date |
|
/APPS/ONE_DT_START_TIME |
Data Element |
Start time |
|
/APPS/ONE_DT_END_DATE |
Data Element |
End date |
|
/APPS/ONE_DT_END_TIME |
Data Element |
End time |
|
/APPS/ONE_ENH_SEND_SPOT |
Enhancement Spot |
Enhancement spot for badi |
|
/APPS/ONE_ENH_SPOT |
Enhancement Spot |
Enhancement spot for badi |
|
/APPS/ONE |
Function Group |
Function group for table maintenance |
|
/APPS/ONE_CON |
Function Group |
Function group for table maintenance |
|
/APPS/ONE_DEC |
Function Group |
Function group for table maintenance |
|
/APPS/IF_ONE_CONSTANTS |
Interface |
Interface for constants used in SIAT/CL_ONE |
|
/APPS/ONE |
Message Class |
Message class |
|
/APPS/RUN_ONE |
Program |
Main program for ONE |
|
/APPS/ONE_CLEAN_UP |
Program |
Clean up report, mainly for testing purposes |
|
/APPS/ONE |
Table |
Leading customizing table |
|
/APPS/ONE_CON |
Table |
Customizing table defining the connection for instances |
|
/APPS/ONE_DEC |
Table |
Decision types |
|
/APPS/ONE_DECT |
Table |
Text table for decision types |
|
/APPS/ONE_DS_ATTACHMENT |
Structure |
|
|
/APPS/ONE_DS_DATA |
Structure |
|
|
/APPS/ONE_DS_XML |
Structure |
|
|
/APPS/ONE_DT_XML |
Table |
|
|
/APPS/ONE_RUN |
Table |
|
|
/APPS/ONE_TASK |
Table |
|
|
/APPS/ONE_USER |
Table |
|
|
/APPS/ONE_WI |
Table |
|
|
/APPS/ONE_TT_ATTACHMENT |
Table Type |
|
|
/APPS/ONE_TT_DATA |
Table Type |
|
|
/APPS/ONE_TT_TASK |
Table Type |
|
|
/APPS/ONE_TT_WI |
Table Type |
|
|
/APPS/ONE_TT_XML |
Table Type |
|
|
/APPS/ONE_DATA |
Transformation |
|
|
/APPS/ONE_CL_WS_BADI_FB |
Class |
BAdi Implementation for sending information by WebService |
The following data will set in standard to a sent decision XML document:
|
Name |
Description |
|
ActionType |
Create, Delete |
|
CompanyId |
Sitrion ONE company id |
|
CompanyPassword |
Sitrion ONE company password |
|
EnvironmentName |
Sitrion ONE environment |
|
MessageType |
Identifier for the type of message for ONE |
|
IndicatorAccept |
Identifier to send an “accept” |
|
IndicatorDecline |
Identifier to send a “reject/decline” |
|
Indicator… |
Further Identifiers |
|
@GENERICTEXT# |
Each line of the task description becomes @GENERICTEXT#001, @GENERICTEXT#002, … |
|
WorkflowId |
Id of the SAP workitem |
|
Subject |
Subject of the workitem |
|
EMailAddresses |
Approvers e-mail addresses |
|
Username |
Approvers SAP user names |
|
UserLanguage |
Approvers SAP user languages |
Tables - Data
The collector contains data tables used to store information about history of runs and items. This information is needed as it is related to future executions.
/APPS/ONE_RUN - information about run
This table contains information about each run per instance.
|
Column |
Description |
|
MANDT |
Client of SAP System |
|
INSTANCE_NAME |
Name of instance the entry is related to |
|
TIMESTAMP |
Timestamp of data evaluation for this run |
|
HAS_ERROR |
Indicates if one or more items had errors |
/APPS/ONE_WI
This table contains information about each work item/notification send or to be sent, there can be more than one entry per work item. There will be one entry per Instance work item and run. The retry value will be increased for every run of related instance. If the max value is reached this item will no longer evaluated by method DETERMINE_ITEMS.
|
Column |
Description |
|
MANDT |
Client of SAP System |
|
INSTANCE_NAME |
Name of instance the entry is related to |
|
WI_ID |
ID of related work item from SWWWIHEAD |
|
USERNAME |
User the work item is related to (receiver) |
|
DET_TIMESTAMP |
Timestamp of evaluation of data |
|
SEND_TIMESTAMP |
Timestamp of sending this item (or at least the try to) |
|
RETRY |
Number of try since initial run |
|
STATUS |
Result of run ERR-erroneous SUC-successful |
|
DESCRIPTION |
Description of issues occurred |
The collector uses several customizing tables described in the following chapters. All relevant tables do have a maintenance view with the same name as the table itself.
/APPS/ONE
This is the main customizing table to define the different instances. Technically an instance is just an identifier used to customize values, task and user used during runtime. Each active instance will be considered during a run. Some of the values contained in customizing are not considered in base implementation e.g. start & end. It’s up to the implementation of the enhancements to use these.
|
Name |
Description |
|
MANDT |
Client of SAP System |
|
INSTANCE_NAME |
Name of instance |
|
CON_TYPE |
Defines the type the data is send |
|
TEMPLATE_ID |
Type this is an ID used to identify the related process in Sitrion One an part of the notification message |
|
INCL_SUBST |
Flag if substitutes should be considered as receiver |
|
ACTIVE |
Flag if this instance is active |
|
OVERWRITE |
Indicates that the start and end of the appointment (if there are these dates) should be overwritten by the defaults defined in start/end date/time column of this table |
|
MAX_RETRY |
Defines the max number of retries |
|
WITH_DESCRIPTION |
Defines if the description of the work item is to be included in data |
/APPS/ONE_CON_TY
This table defines the connection types. A connection type is the starting point to define a new way for sending the data. Mail and Web Service are defined in standard.
|
Name |
Description |
|
MANDT |
Client of SAP System |
|
CON_TYPE |
ID of connection type |
/APPS/ONE_CON_TT
This table defines language dependent texts for connection types.
|
Name |
Description |
|
MANDT |
Client of SAP System |
|
LANGU |
Language key |
|
CON_TYPE |
ID of connection type |
|
CON_TEXT |
Description of the connection type |
/APPS/ONE_CON_F
This table defines the available fields per connection type. Each field defines a property which is used by a connection type.
|
Name |
Description |
|
MANDT |
Client of SAP System |
|
FIELD |
ID of field |
/APPS/ONE_CON_FT
This table defines the language dependent field description.
|
Name |
Description |
|
MANDT |
Client of SAP System |
|
LANGU |
Language key |
|
FIELD |
ID of field |
/APPS/ONE_CON_FV
This table defines the language dependent field description.
|
Name |
Description |
|
MANDT |
Client of SAP System |
|
CON_TYPE |
Connection type |
|
FIELD |
ID of field |
|
FIELD_VALUE |
Value for field ID |
/APPS/ONE_DEC
This customizing table defines the decision alternatives for the possible decisions ACCEPT, REJECT and OTHER. It is related to a task ID. In case no task ID is defined this entry is used as fallback. This table has a related text table /APPS/ONE_DECT for language dependent text of decision.
|
Name |
Description |
|
MANDT |
Client of SAP System |
|
TASKID |
ID of the related task |
|
DECISION_TYPE |
Type of decision ACCEPT; REJECT, OTHER |
|
DECISION_NUMBER |
Number of decision |
/APPS/ONE_TASK
This table is used to define which task should be used for data evaluation for related instance. If this table is left blank for an instance all tasks will considered.
|
Column |
Description |
|
MANDT |
Client of SAP System |
|
INSTANCE_NAME |
Name of instance the entry is related to |
|
TASK |
Workflow Task ID to be considered for instance defined by instance_name |
|
WORKFLOW |
Can be used to define the workflow containing the task (not used at the moment) |
|
NEW_ONLY |
Flag if only new entries should be used for data determination new = status “READY” (not used at the moment) |
|
WI_DESCRIPTION |
Description field |
/APPS/ONE_USER
This table contains Users or ranges of users to be excluded from the result. It is built like a selection structure to be able to define ranges.
|
Column |
Description |
|
MANDT |
Client of SAP System |
|
INSTANCE_NAME |
Name of instance the entry is related to |
|
SEQ_NR |
Sequence number |
|
SEL_SIGN |
Selection sign - refer to SAP standard help for more details |
|
SEL_OPTION |
Selection option - refer to SAP standard help for more details |
|
SEL_LOW |
Low value - refer to SAP standard help for more details |
|
SEL_HIGH |
High value - refer to SAP standard help for more details |
For this program the exception handling is used to handle and report errors and issues. The exception class /APPS/CX_ONE was implemented for this. Errors can be found in application log (TA SLG1) and in history tables mentioned above. For application log a new object /APPS/ONE_LOG was created. To get information about run and item information the methods GET_RUN_INFO and GET_WI_ITEMS of class /APPS/CL_ONE can be used after execution.
Integration of customer workflows
As described in the Initial Configuration the configuration expects a setup which workflow user decision step has to be pushed. Doing this we register the decision tasks for the ONE collector. Since each workflow is custom there is a need to implement an enhancement through explicit Enhancement Spots on your SAP system to read the related workflow data. This implementation will be held in custom namespace mostly Z* or Y*.
Example
The BAdI Enhancement spot /APPS/ONE_ENH_SPOT ONE gets enhanced though custom implementation class ZCL_BADI_IMPL_ONE_BANF
The call implements the interface method /APPS/ONE_IF_BADI~CHANGE_DATA where each decision task has to be processed so be able to be consumed by Sitrion ONE.
Method parameters:
Example of Purchase Requisition Task integration:
* Purchase requisition decision task
IF iv_wi_head-wi_rh_task EQ 'TS99200002'.
" get related objects to work item - need to evaluate banf number
CALL FUNCTION 'SAP_WAPI_GET_OBJECTS'
EXPORTING
workitem_id = iv_wi_head-wi_chckwi
language = sy-langu
TABLES
objects_2 = lt_objects.
READ TABLE lt_objects INTO ls_object WITH KEY typeid = 'BUS2105' catid = 'BO'.
IF sy-subrc EQ 0.
lv_banfnr = ls_object-instid.
ENDIF.
CHECK lv_banfnr IS NOT INITIAL.
" read related purchase requisition data
CALL FUNCTION 'BAPI_REQUISITION_GETDETAIL'
EXPORTING
number = lv_banfnr
account_assignment = 'X'
item_texts = 'X'
services = 'X'
service_texts = 'X'
TABLES
requisition_items = requisition_items
requisition_account_assignment = requisition_account_assignment
requisition_text = requisition_text
requisition_limits = requisition_limits
requisition_contract_limits = requisition_contract_limits
requisition_services = requisition_services
requisition_services_texts = requisition_services_texts
requisition_srv_accass_values = requisition_srv_accass_values
* convert SAP data to ONE à ct_data[]
"Purchase Requisition ID
ls_data-order_no = lv_ordernr.
ls_data-key = 'BANFNR'.
CONCATENATE '<![CDATA[' lv_banfnr ']]>' INTO ls_data-value.
APPEND ls_data TO ct_data.
CLEAR ls_data.
lv_ordernr = lv_ordernr + 1.
"evaluate all related items
LOOP AT requisition_items ASSIGNING <ls_requisition_items>.
ls_data-order_no = lv_ordernr.
CONCATENATE 'ITEM_' <ls_requisition_items>-preq_item '_CREATED_BY' INTO ls_data-key.
CONCATENATE '<![CDATA[' <ls_requisition_items>-created_by ']]>' INTO ls_data-value.
APPEND ls_data TO ct_data.
CLEAR ls_data.
lv_ordernr = lv_ordernr + 1.
"Product
ls_data-order_no = lv_ordernr.
CONCATENATE 'ITEM_' <ls_requisition_items>-preq_item '_ARTICLE' INTO ls_data-key.
CONCATENATE '<![CDATA[' <ls_requisition_items>-short_text ']]>' INTO ls_data-value.
APPEND ls_data TO ct_data.
CLEAR ls_data.
lv_ordernr = lv_ordernr + 1.
"Quantity
ls_data-order_no = lv_ordernr.
lv_tmp_string = <ls_requisition_items>-quantity.
CONDENSE lv_tmp_string.
lv_quantity = <ls_requisition_items>-quantity.
CONCATENATE 'ITEM_' <ls_requisition_items>-preq_item '_QUANTITY' INTO ls_data-key.
CONCATENATE '<![CDATA[' lv_tmp_string ']]>' INTO ls_data-value.
APPEND ls_data TO ct_data.
CLEAR ls_data.
lv_ordernr = lv_ordernr + 1.
* "UNIT
ls_data-order_no = lv_ordernr.
CONCATENATE 'ITEM_' <ls_requisition_items>-preq_item '_UNIT' INTO ls_data-key.
CONCATENATE '<![CDATA[' <ls_requisition_items>-unit ']]>' INTO ls_data-value.
APPEND ls_data TO ct_data.
CLEAR ls_data.
lv_ordernr = lv_ordernr + 1.
"PRICE
ls_data-order_no = lv_ordernr.
lv_tmp_string = <ls_requisition_items>-c_amt_bapi.
CONDENSE lv_tmp_string.
lv_price = <ls_requisition_items>-c_amt_bapi.
CONCATENATE 'ITEM_' <ls_requisition_items>-preq_item '_PRICE' INTO ls_data-key.
CONCATENATE '<![CDATA[' lv_tmp_string ']]>' INTO ls_data-value.
APPEND ls_data TO ct_data.
CLEAR ls_data.
lv_ordernr = lv_ordernr + 1.
"PRICE per UNIT
ls_data-order_no = lv_ordernr.
lv_tmp_string = <ls_requisition_items>-price_unit.
CONDENSE lv_tmp_string.
lv_price_unit = <ls_requisition_items>-price_unit.
CONCATENATE 'ITEM_' <ls_requisition_items>-preq_item '_PRICE_UNIT' INTO ls_data-key.
CONCATENATE '<![CDATA[' lv_tmp_string ']]>' INTO ls_data-value.
APPEND ls_data TO ct_data.
CLEAR ls_data.
lv_ordernr = lv_ordernr + 1.
"CURRENCY
ls_data-order_no = lv_ordernr.
CONCATENATE 'ITEM_' <ls_requisition_items>-preq_item '_CURRENCY' INTO ls_data-key.
CONCATENATE '<![CDATA[' <ls_requisition_items>-currency ']]>' INTO ls_data-value.
APPEND ls_data TO ct_data.
CLEAR ls_data.
lv_ordernr = lv_ordernr + 1.
"Position sum
lv_pos_sum = lv_price * lv_quantity.
ls_data-order_no = lv_ordernr.
lv_tmp_string = lv_pos_sum.
CONDENSE lv_tmp_string.
CONCATENATE 'ITEM_' <ls_requisition_items>-preq_item '_POS_SUM' INTO ls_data-key.
CONCATENATE '<![CDATA[' lv_tmp_string ']]>' INTO ls_data-value.
APPEND ls_data TO ct_data.
CLEAR ls_data.
lv_ordernr = lv_ordernr + 1.
lv_ges_sum = lv_ges_sum + lv_pos_sum.
ENDLOOP.
"total sum evaluation
ls_data-order_no = lv_ordernr.
lv_tmp_string = lv_ges_sum.
ls_data-key = 'ITEM_TOTAL_SUM'.
CONCATENATE '<![CDATA[' lv_tmp_string ']]>' INTO ls_data-value.
APPEND ls_data TO ct_data.
CLEAR ls_data.
lv_ordernr = lv_ordernr + 1.
ENDIF. "decision task end
The SharePoint collector can be used to listen on SharePoint lists, document libraries or task list. The collector itself gets deployed as a SharePoint solution package (WSP).
The deployment of the WSP can be executed by using the following PowerShell statements:
Add Solution to SharePoint
Add-SPSolution -LiteralPath C:\temp\Sitrion.ONE.SharePoint.wsp
Deploy the solution
Install-SPSolution -Identity Sitrion.ONE.SharePoint.wsp -GACDeployment
Activate needed features
Install-SPFeature -path Sitrion.ONE.SharePoint_ONEInstaller\Feature.xml
Install-SPFeature -path Sitrion.ONE.SharePoint_CardPublisherSite\Feature.xml
Install-SPFeature -path Sitrion.ONE.SharePoint_CardPublisherFarm\Feature.xml
Once you've executed the deployment, you can do the initial configuration.
Through the deployment you got the ability to create a new Service Application called "Sitrion ONE Service"
Once you created the service application, you've to configure your ONE tenant settings, mainly the Company Password and Company-ID.
You can find both values on the "Get started" section on one.sitrion.com
The environment is by default: https://one.sitrion.com should there be a case, that your SharePoint environment can't connect straight to the Cloud. You can use our Card Webservice as a bridge/proxy between your OnPrem environment and the Cloud.
When you saved this one time configuration, you can go ahead and configure the lists, you would like to use for the SharePoint collector.
The list itself can be configured by using the "Sitrion ONE Card Publisher Settings" in the given Site Settings, where the list itself is located (should the Sitrion ONE Card Publisher Settings not be available here, please check if the Site Collection Feature for the Sitrion ONE collector, "Sitrion ONE Card Publisher", is active).
If you haven't configured any list yet, you'll see the following screen, where you can create a "New Connection".
In the connection settings, you
1. Select a SharePoint List
2. Define the events on which the collector should executed
3. Define the Message Type (the Message Type is the identifier for the Card you've to build with the AppBuilder)
4. Select the needed columns and save the selection.
From now, evertime when you modify something in the list, the ONE collector gets executed on the given event, and sends the data directly to the ONE cloud.
The cloud itself will check if a Card is available for the metadata, for the given MessageType, you just send. If a card is available, it'll execute the "Translate" method in the card and will provide the card to the given users.
When you've saved a connection, you can modify it by using the Edit button and also have the option to "Generate Sample Data". The sample data is helpful when you start building the Card in AppBuilder.
The cloud has an own Card API, which allows you to connect with from a certain backend systems.
Cards have basically two components.
The first one is the UI which gets designed by using the AppBuilder.
The second component is the backend data. The handling on cards is different than it is for Micro-Apps. Micro-Apps are pulling data from a backend system while Cards get data pushed from a backend. For cards, ONE is using a Card API in the cloud. The Card API is based on a REST endpoint.
The endpoint URL is https://one.sitrion.com/api/v2/cardpublisher/write which requires your company id and your customer secret for authentication. The card data is provided within a card routing object as JSON.
The web request needs two header objects for authentication:
Authorization = “sitauth ”+CompanyPassword as Base64
Sample: If company password is “MyCompanySecret, the header would be
Authorization = “sitauth TXlDb21wYW55U2VjcmV0”
sitrion-companyId = CompanyId as string
Sample: If my company id is “FEA28DF4-3B31-489B-AE7A-43B5B19CE878”, the header would be
sitrion-companyId = “fea28df4-3b31-489b-ae7a-43b5b19ce878”)
The body needs to contain the card routing object as JSON:
{
"Actor": {
"DisplayName": "John Doe",
"Email": "john.doe@sitrion.com"
},
"SendTo": [
{
"DisplayName": "Jane Doe",
"Email": "jane.doe@sitrion.com"
}
],
"CardId": "31483b47-2b27-459e-8da4-5c0936534f3a",
"MessageType": "MyCard",
"ActionType": 1,
"Data": {
"PurchaseOrderId": "123456789",
"Title": "New Purchase Order"
},
"CardDate": "2015-05-26T13:31:21.2383418Z"
}
ActionType = 0=None, 1=Create, 2=Update, 3=Delete
Initially you have to create a card, with the card id you can also execute other action on the same card
CardDate
The datetime which shows up in the header of a card (recommend UTC time)
CardId
This needs to be a unique id for your card, this id can be used later for card actions like delete or update
MessageType
This is the identifier between the metadata you're sending here and the card UI, which you have to build with the AppBuilder
Actor
This get's displayed in the card header as the person who sent the card, if the Email property matches a ONE user, the profile picture on the card will be retrieved based in this
SendTo
With SendTo you can define the ONE users which should receive this card, if you keep SendTo empty, everyone who has assigned this card in a role will receive the card
Data
Data is a simple Dictionary which you can be prefilled with the data which you would need on a card
You can find a sample solution based on .NET code in our GitHub repository, this contains also a JSON sample incl. a JSON schema.
The Microsoft Office 365 collector works similar like the SharePoint collector. Based on the fact, that it's running on Office 365, instead of deploying it manually you can get the collector from the Office 365 store.
Collectors are usually connecting directly to the card REST web service in the Cloud. In some infrastructures, this might not be always feasible. Based on this you can install an on-premise web service which can talk to the Cloud web service. The Card Webservice is a SOAP and REST based web service, which can be used as a kind of relay between the on-premise world and the ONE cloud. The Card Webservice often gets installed on the same machine where the Hub is installed, because that machine has already outbound connectivity to the Cloud.
Your internal system (e.g. SharePoint, SAP) can now connect to the Card Webservice which is installed internally and the Card Webservice simply passed the data through to the Cloud.
One example where this is used is the SAP collector. SAP doesn't connect directly to the internet in most cases and often doesn't allow to connect to REST services, like the ONE card service in the cloud is built for. The Card Webservice in this case takes an XML extract from SAP and converts it into JSON to pass it to the Cloud's REST endpoint.
The other example is when a SharePoint isn't allowed to connect straight to the internet, you can simply use the build in REST webservice of this Card Webservice as your internal proxy. The REST endpoint of the Card Webservice simply passes the incoming JSON to the Cloud's REST endpoint.
The Card Webservice ("Collector Proxy") can be downloaded in the "Get Started" section of the admin portal on one.sitrion.com.
To install the Card Webservice, please make sure that the machine where you install the Card Webservice has the following prerequisites:
Operating System
Windows 10, Windows 7 Service Pack 1, Windows 8, Windows 8.1, Windows Server 2008 R2 SP1, Windows Server 2012, Windows Server 2012 R2
.NET Framework 4.6 (Full Installation)
Installed Internet Information Server (IIS) role incl. ASP.NET and WCF Activation Features
Connectivity
The Card Webservices requires outbound access on HTTP port 443.
Since the Cloud is hosted on Microsoft Azure Datacenters, we suggest opening this ports on the machine where the Card Webservice is installed for any IP. Should you have a need to target only specific IP's, Microsoft offers the Windows Azure Datacenter IP Ranges here: http://msdn.microsoft.com/en-us/library/azure/dn175718.aspx
ONE is currently hosted in the following Azure datacenters:
- West US (California)
- West Europe (Netherlands)
Hardware
The Card Webservice is a lightweight component. Based on this, the hardware requirements for the Card Webservice are corresponding to the given operating system and installed features (e.g. NET Framework).
As a suggestion we give the following requirements:
Minimum:
- Single CPU with minimum of two cores
- 4 GB RAM
- 10 GB free disk space
Recommended:
- 2 CPU's (each with a minimum of 2 cores)
- 8 GB RAM
- 10 GB free disk space
Of course the Card Webservice can run also in a virtualized environment.
The following screen shows the Setup program of the Card Webservice
Click Next to continue.
Destination Folder
Choose the folder for the Card Webservice to be installed in.
Click Next to continue.
User Settings
Configure the user for the Application Pool. If not changed, it will install with the Network Service account on the installed machine.
Click Next to continue.
Website Settings
Configure the Website Name and the port which is used in the IIS for the Card Webservice
Click Next to continue.
Company Id / Shared Key / Environment Name
The Company Id and Shared Key are the identifieres of your tenant. You can retrieve your own company Id on one.sitrion.com.
The environment name should by default target to https://one.sitrion.com.
Ready to install
Click Install to start the installation of the Card Webservice on your machine
Finish
The Card Webservice is now installed.
Click Finish to exit the setup.
Validate
To validate if the card webservice is hosted you can check if the WSDL is accessible
The service should be accessed via the following URL if you used the default settings http://localhost:8095/CardService.svc?singleWsdl
You may have to adjust "localhost:8095" to your corresponding name and port.
FYI: The REST endpoint of the webservice is hosted straight on the base URL, which would be in the default installation "http://localhost:8095". Reflecting this e.g. for the SharePoint collector: Instead of using https://one.sitrion.com as the environment name, you would configure "http://mycardwebservicemachine:8095" (where mycardwebservicemachine is the name of the place where you installed the Card webservice and of course the corresponding port).
The proxy configuration itself needs to be configured manually in the config file of the Card Webservice. The config file is by default located in the folder "C:\Program Files\Sitrion\Sitrion ONE Card Webservice\Web.config". The file itself is a default .NET configuration file where a proxy can be configured with .NET defaults, like described in this MSDN article.
Connectors are used for integrating Micro-Apps with specific backend systems such as SAP, SharePoint or REST services. They have a design-time and run-time component. At design-time a connector can be used in the AppBuilder to browse backend system elements and types. Micro-Apps use Connectors at runtime for sending or receiving data from these systems.
Connector can also be used on Cards, to integrate card actions (e.g. approve/reject on approvals cards) with backend systems.
For Sitrion SmartRoutines we provide to different types of Connectors:
Sitrion SmartRoutines (SAP NW Gateway) - Connects through SAP NetWeaver Gateway to SmartRoutines SAP models
Sitrion SmartRoutines (SAP RFC) - Connects through SAP RFC to SmartRoutines SAP models
The Sitrion SmartRoutines connectors give you the capability to connect to our SmartRoutines communication layer which can be based on the given connection types (RFC/Gateway). SmartRoutines uses a proven mechanism to connect directly to ABAP objects through this connectivity layers.
In addition to use pre-defined connectors, your also able to use custom code inside of a Card or Micro-App.
Custom Code can be added manually or by using the Data & Actions option "Add Data Source" -> Select "Custom Service" as a Datasource.
For both ways, manually or by using the wizard, you'll have a class preferably in the Services or DataTypes folder, which uses the attribute "OneService" to get recognized by the designer.
The same goes for custom datatypes. They also can be coded. It's required to use the DataContract and DataMember attribute above the given class and property definition.
The SharePoint connector allows you to consume on premise SharePoint lists and document libraries from your SharePoint 2010/2013 environments.
Note on SharePoint Online Connectivity
The connector also allows SharePoint Online connectivity. For SharePoint Online, please make sure that you've installed the SharePoint Server 2013 Client Components SDK on the machine where the ONE Hub is installed and on the machine, where the AppBuilder is installed.
Video Tutorial
Sitrion ONE - Read Data from SharePoint
The REST connector allows you to access on premises RESTful services based incl. security like Username/Password or Anonymous authentication.
Video Tutorial
Sitrion ONE - Connecting to a REST service
The SAP RFC connector allows you to connect via the RFC connection layer to your on premise SAP system.
The SAP RFC connecitvity is performed through SAP's librfc32.dll.
If you want to use the SAP RFC connector, make sure your hub and also the machine where you use the AppBuilder has this dll's in place.
LibRfc32 Installation on a 32 Bit OS
Copy the LibRfc32.dll (32 Bit Version, also installed when you install SAP GUI/SAP Logon) into the C:\Windows\System32 Folder.
LibRfc32 Installation on a 64 Bit OS
Copy the LibRfc32.dll (64 Bit Version, Download via SAP SDN) into the C:\Windows\System32 Folder.
Copy the LibRfc32.dll (32 Bit Version, also installed when you install SAP GUI/SAP Logon) into the C:\Windows\SysWOW64 Folder (this Folder means System Windows on Windows 64)
The LibRfc32 requires the Visual C++ 2005 Runtime. Please make sure this is installed on the given machine
RFC (BAPI)
RFC's can be accessed through this connectors. The only requirement is, that the given function modules has the processing type marked as a "Remote-Enabled Module" in SAP.
Tables
SAP tables can also be accessed through the connector (read only). Since tables are by default not accessible from outside SAP, internally the standard SAP RFC "RFC_READ_TABLE" supports the connector to consume SAP tables.
Video Tutorial
Sitrion ONE - Read data from a SAP RFC
ONE is built for extensibility, so if you haven't found a Connector or Collector for your backend system. Please contact us.
Comments
0 comments
Please sign in to leave a comment.